As part of deploying Starlink as my primary internet provider, I had to renumber my LAN. Starlink uses 192.168.1.0/24 as its default client network and that is not alterable, so far as I can tell.
pfSense didn’t know when I started configuring it, so it didn’t argue, but also didn’t work. I finally took a guess that the same IP on both sides of the router could confuse it and changed mine to 192.168.2.0/24 and my stuff started working!
Well, it did until the first time I connected to my work VPN, Cisco AnyConnect. At first, I didn’t specifically notice that the VPN was the trigger. I was working away at something and wanted to check on my camera system to see if the mail had arrived, but I couldn’t get to my NAS. I didn’t panic or anything, but later (without realizing that the VPN was disconnected, I was able to reach the NAS and cameras just fine. Some time later still, I connected the VPN then tried to refresh the camera display and it finally dawned on me that with the VPN connected, I couldn’t get to the NAS. I tried to verify the issue by connecting to something else, one of the switches I think, and: no luck. Disconnect VPN, get right in. Reconnect VPN, get nowhere. Well, expect for my router. I suppose the VPN needs the default gateway.
AnyConnect info includes a list of secured routes. It turns out there are secured routes cover most, though thankfully not all, of RFC-1918 address space. All of 10.0.0.0/8 is either in use or allocated internally. Quite a few legacy locations use various ranges within 192.168.0.0/16, especially in the bottom half or so. Finally, there are only a few used within 172.16.0.0/12.
I dashed off a note to the network team exlaining my issue and asking for assistance in finding a subnet I could use without interference, but that note as yet has not been answered. I used my Linux jumpbox, which is a VM in one of our data centers, to investigatively Nmap parts of this space, looking for some vacant space. Running Nmap from home is limited to only the secured routes provided through AnyConnect; running it from the data center should also detect systems that are not specifically accounted for in the VPN.
First run through, it looked like a large block near the top of the 192.168.0.0/16 space should be open. I chose 192.168.250.0/24 as being easy to remember and easy to type.
Even though I was just testing, I was still going to have to update the DHCP reservations I have because the devices I need to be able to reach all have reserved IPs. The process is to edit the LAN IP address, but don’t apply the changes yet, edit all of the DHCP reservations, then apply the changes under both menus.
As soon as you apply those changes, the IP you are using to connect to the router will no longer be valid, so you need to refresh your IP address then log in to the router again.
And it still interferes with the VPN.
Just for the entertainment value, I tried 192.168.1.0/24 again, but this time, since the gateway for Starlink was already connected, pfSense wouldn’t let me use it.
I then went to my next alternative, the 172.16.0.0/12 range. There are a couple in use, but they are at the low end of the range. Ages ago, we had a WAN provider that had assigned the entire 172.28.0.0/14 range to our company within their network. At that time, about half of our branches were numbered as 172.29.X.0/24 or 172.30.X.0/24, where X was the branch number and 29 or 30 revealed whether that location connected via VPN over internet or a point to point T1. It worked well for us. It was fun to realize that my muscle memory could still type 172.29.0.1 really fast, so….
I renumbered my LAN again to 172.29.0.0./24 and FINALLY, all my stuff coexists with the work VPN!