Introduction

My network up until now has had no VLANs or seperation at all. This didn’t bother me, but I’ve also started to approach the end of my IP range. I decided that it was time to reconfigure my network so I could seperate different services into different VLANs.

Network Diagram

I had created network diagrams in the past, but it never was that in depth and often was out of date very often. I decided that before I did anything, I had to plan out how my network would look. I used Draw.io and this shape library from TechGeek01 on Reddit. I took heavy inspiration from their diagram when creating mine. I spent a lot of time rearranging everything until I thought it was enough. I was then ready to begin modifying my network.

Adding an Interface

The I350-T4 in my pfSense box had four RJ45 ports. One connected directly to my ISP, while another connected to a switch for the rest of my network. I decided that I would assign another IP to another port for another part of my network.

I went to Interfaces > Interface Assignments and added an unassigned port from the list of available ports. Inside the configuration, I gave it a description, enabled the IPv4 Configuration Type, and set it to IPv4 Static. Under IPv4 Address, I created a new range 10.120.30.1 with a subnet of 24. After double checking, I saved the configuration.

DHCP Server

I thought it would’ve been that simple to create another IP range, but I was wrong. When I plugged in my laptop into the newly assigned port, I got no IP. I wondered why I wasn’t getting assigned an IP address from the DHCP server, so I did some Googling. I then realized that I needed to enable DHCP server for the new IP and to provide a range. I went into Services > DHCP Server and enabled the server with a range that I thought was appropriate.

After that, I did end up getting an IP, but I wasn’t getting any internet access. At this step I was also moving over the IPs of my current servers, so I thought it had something to do with Pi-Hole not working well with the new IP address. I went into the dashboard and saw that my requests were actually being processed.

Firewall Rules

I compared my current working LAN with the new LAN. I saw that the firewall rules were different, so I made a copy of the rules from my LAN and changed the interface. That didn’t fix the problem and after quite a bit of YouTube searching, I found Lawrence Systems’ troubleshooting video. Very quickly, he said that by default all internet traffic was blocked, and I decided to look over my rules again. I realized that I only changed the inferface and not the source of the traffic. Once I changed the source, everything else worked perfectly fine.

Moving Over Services

This part was actually pretty easy, as almost all of my services used DHCP to get their IP address. I created new static mappings and restarted the services so they got their newly assigned IP. I also had to change my SMB mount on my Ubuntu server as it was set to a a specific IP. It was easy enough as I was able to reference my previous blogs.

Changing the Original LAN

I also wanted to change the IP range of my current LAN as it was already clogged full of old IPs and if I wanted to VPN into my network, there might be conflicts. I changed the static IPv4 in the interfaces and then the DHCP server. Everything seemed to go pretty smoothly until I realized my wifi went down.

It turns out that once I changed my LAN, my wireless access point decided that it would stop providing internet access to my devices. I initially tried to install the Omada control software onto one of my Ubuntu VMs, but the AP wasn’t discoverable by the software. I then realized that the IPs were in different ranges and that led me to quite a problem. All of my servers were on a seperate LAN, so I needed to have a server on the AP LAN to configure my wifi.

I had to dust out an old Windows machine as the TP-Link software to discover access points wasn’t on Mac OS. The access point was picked up and I tried adopting it to my Ubuntu Omada controller, but luck wasn’t on my side. The adoption failed and I had to try another method. I set up the Omada control software on my Windows machine, but I wasn’t picking up the access point during set up. After going back and forth between the discovery software and the controller, I decided to finish the set up of my controller. It was only after all the set up was done, that the software picked up the access point. I adopted it and everything after that was smooth sailing.

Conclusion

I knew working with networking was going to be a pain, but I really didn’t know what I was getting into. Luckily, the moving of my services went smoothly, but I didn’t expect my wifi to go down. It was helpful having a network diagram as I knew what DHCP leases I should assign each device. This has reminded me that if it ain’t broke, I shouldn’t “fix” it.