VPN Client Cannot Connect Through pfSense
-
I setup a spare machine as a bridge so I could get some packet captures from a neutral viewpoint. The resulting captures are at http://www.kc8apf.net/files/. With 1.2.3 and a default config, I was never able to establish a VPN connection. I tried turning off hardware checksumming, TSO, and all of the PF rules other than NAT (edited rules.debug and loaded it with pfctl -f). None seem to have any effect.
I don't have too much experience looking at Wireshark output. I know the various protocols reasonably well, but the display and interpretation is a bit confusing. Anyway, it seems that with 1.2.3 the fragments for the UDP packet for NAT-T have bad header checksums. That prevents the packet from being reassembled. When I had taken captures of the same traffic from pfSense (I don't have the captures anymore), the headers were shown as intact. Between that and my testing with other NICs, this seems to be specific to the 'em' driver and happens after PF has seen the packet.
I installed the latest 2.0 snapshot with a default config. The VPN connected on the first try. I'm not sure what the exact bug is (there seem to be a few possible problem reports against em), but it seems to be resolved in FreeBSD 8.0. This is good to know, but I'm very hesitant to use the 2.0 snapshots for my live system. I run a number of domains through that router and can't risk having it behave sporadically. At least for the moment, I'll just need to live without a working VPN connection to work.
-
Any chance you can use a NIC with different driver for now?
-
Considering the machine I'm using is a single-board computer with 4 ems and 1 fxp and all of them are in use. No, not really.
-
Ugh :)
-
I've still not had chance to try my ESXi setup, with a different "virtual" NIC. Hopefully sometime over the weekend. I'll report back once I finally get to it.
I'm also getting an HP T5720 Thin Client that I'm planning on using for pfSense. I'll try with that as well, once it arrives.
Cheers.
-
Ah well, bloody typical. Today is the first day my wife has telecommuted for a couple of weeks, so I was hoping that I could finally prove, or disprove, kc8apf's conjecture that the 'em' driver was the root cause of these issues.
However, between then and now, her company has changed their VPN software. The current software connects, without issue, through my current setup. >:(
So kc8apf, I'm sorry I can no longer check if switching the NIC driver, from 'em', to something else fixes the issue with the fragmented UDP packets. :(
Cheers.
-
I can confirm that the em driver has nothing to do with the issue. I have machines with both fxp and em nics and they both do the exact same thing. I actually waited a while before upgrading to 1.2.3 from 1.2.2 to avoid this kind of issue. This SUCKS! Anyone done a downgrade from 1.2.3 to 1.2.2? How did it go?
Roy
-
I would have been surprised. It would be interesting to know what the protocol difference between the old and new VPN software is. That might make it more feasible to come up with a theory. As far as 1.2.2 vs 1.2.3, one thing that would be helpful would be to save /tmp/rules.debug from 1.2.3 - do a fresh 1.2.2 install, restoring the config and then compare the two files. Might not be helpful due to lots of pf rules noise, but maybe it would.
-
You have to set the static port in the manual NAT for both the ingress and egress interface. Ie if the traffic is coming from the LAN interface out the WAN interface, you need 2 NAT rules with static ports on UDP 500, one on each interface with the same source and destination. 1.2.2 only required the one on the egress interface.
Roy
-
Ok while adding the static port entry on both interfaces got it working, it only stays working for about 2-3 hours. Then you have to reset the state table to get it to connect again. Anyone have an idea why that is? For obvious reasons, resetting the state table is not a viable workaround.
Thanks,
Roy