James Liang/Changing Network Config

Created Fri, 17 Dec 2021 00:00:00 -0500 Modified Wed, 05 Jan 2022 17:03:32 +0000
913 Words


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 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.


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.