Incoming VPN connections not working
-
I recently had to swap out my ATT gateway. When connecting the new ATT router to my pfsense it picked up a LAN address of 192.168.1.65. Internet works no issue but my site 2 site VPNs are down.
I went ahead and switched to IP Passthrough and a few VPN tunnels came back but I noticed my wireguard tunnels did not. After some investigating I see state that's pretty new to the old LAN address of 192.168.1.65. That doesn't make sense. PFsense has a public IP now yet I see state.
In fact I have cleared the states numerous times and yet it keeps coming back
arp table doesn't even see that IP.root: arp -a | grep 192.168.1.65 [23.09.1-RELEASE][admin@G]/root: arp -a | grep 192.168.1.For example:
I don't understand whats happening
pfSense doesn't seem to own that IP.
]/root: ifconfig | grep 192.168.
inet 192.168.50.254 netmask 0xffffff00 broadcast 192.168.50.255
inet 192.168.50.100 netmask 0xffffffff broadcast 192.168.50.100
inet 192.168.50.250 netmask 0xffffffff broadcast 192.168.50.250
inet 192.168.50.173 netmask 0xffffffff broadcast 192.168.50.173
inet 192.168.50.1 netmask 0xffffffff broadcast 192.168.50.1
inet 192.168.3.1 netmask 0xffffff00 broadcast 192.168.3.255
inet 192.168.69.1 netmask 0xffffff00 broadcast 192.168.69.255
inet 192.168.15.1 netmask 0xffffff00 broadcast 192.168.15.255
inet 192.168.23.1 netmask 0xffffff00 broadcast 192.168.23.255
inet 192.168.14.1 netmask 0xffffff00 broadcast 192.168.14.255
inet 192.168.11.1 netmask 0xffffff00 broadcast 192.168.11.255
inet 192.168.17.1 netmask 0xfffffff8 broadcast 192.168.17.7
inet 192.168.141.1 netmask 0xffffff00 broadcast 192.168.141.255
inet 192.168.99.1 netmask 0xffffff00 broadcast 192.168.99.255 -
@michmoor said in Incoming VPN connections not working:
I recently had to swap out my ATT gateway. When connecting the new ATT router to my pfsense it picked up a LAN address of 192.168.1.65. Internet works no issue
Connecting a router (ATT gateway or ATT router) on a pfSense LAN port ? Why do you need a router behind a router ?
The ATT got the 192.168.1.65 from pfSense ?
VPN : VPN clients ? Running on the ATT ? pfSense ?
Read the intro several times, and I've still doubt about the "what is connected to what in what order".
-
@Gertjan
??
The att gateway is on the WAN port of pfsense. -
If the ATT is in front of pfSense, then the WAN of pfSense became "192.168.1.65" then how can this be :
@michmoor said in Incoming VPN connections not working:
PFsense has a public IP now
edit : (coffee starts having effect) :
@michmoor said in Incoming VPN connections not working:
I went ahead and switched to IP Passthrough
You've put the Att in "IP Passthrough" mode.
-
So was the AT&T gateway using the 192.168.1.X subnet before you put it in pass-through mode?
It seems likely to be a stale state from that.
-
@stephenw10
That’s exactly it. I received an IP from the ATT gateway prior to enabling pass through.
What I don’t understand is why pfsense was still actively creating state for the 192.168.1 after it got the public WAN IP.
I can understand the ATT router still believing that my pfsense had the private IP it gave out(blame it on stale info) but I don’t understand why pfsense was creating new state for an IP it no longer has -
Yup that does seem unexpected. The AT&T gateway must still be handling that traffic even though it's now in pass-through mode.
If the state still exists pfSense will try to use it. -
@stephenw10
That’s the bit I’m confused about.
Pfsense will still create NEW state for an IP it doesn’t own(even though it once did) ?So in my case I saw my wireguard peer kept attempting to initiate a handshake but in the state table it was to the 192.168.1. Address that pfsense had. I delete that state and I will see new state for it a few moments later.
-
Are you sure the state didn't still exist? Did the source port remain the same for example?
-
@stephenw10
Right now I can’t say for certain.
I used Diagnostic > States and used the option to kill all states matched by the filter.
I want to say it kept seeing new states 10s after the fact. Hard to conclude now :( -
Yeah sometimes that will fail to kill states because it can filter the display by somethings that cannot be applied to the kill command. I always recommend immediately refiltering to be sure the states are actually gone. If the random source port or translated source port remains the same that's a pretty good sign the state remains.
-
@stephenw10
Gotcha. So in the future you’re saying I should do a filter reload? -
Nope filter-reload doesn't clear existing states.
I'm saying if you use the kill states button in the state table page you should refresh the table afterwards to be sure the states were actually killed.
If you use the trash-can icon next to each states it kills by state ID which should always work.
