IKEv2 / ISAKMP from iOS device behind pfSense / NAT-T not working
-
@cmb:
Filter for :4500 under Diag>States, what do the matching states look like?
Here's a representation of what states look like when I filter for [VPN Gateway] under Diags > States:
INT PROTO Source -> Router -> Destination State LAN udp [VPN Gateway]:500 <- [iOS device internal IP] MULTIPLE:MULTIPLE WAN udp [pfSense WAN IP]:500 ([iOS device internal IP]:500) -> [VPN Gateway]:500 MULTIPLE:MULTIPLESo the initial IKE (500/udp) traffic is there, but no mention at all of the ISAKMP 4500/udp traffic. It also shows there isn't an existing NAT on that port to the same destination server.
Very odd :-\
-
Where/how are you seeing the 4500 traffic leaving without NAT?
You have some no state pass firewall rules defined?
-
@cmb:
Where/how are you seeing the 4500 traffic leaving without NAT?
From a packet capture that I took on pfSense of the WAN interface filtering on all traffic going to the VPN server. I can send to your privately if you like.
@cmb:
You have some no state pass firewall rules defined?
I assume that's a rule where "State type" is set to "none"? If so, no.
The only thing I have that mentions 4500/udp are some traffic shaping rules on the floating tab:
-
If you disable that 4500 floating rule, does it not happen?
-
@cmb:
If you disable that 4500 floating rule, does it not happen?
Disabled all floating rules and reset states, still no go.
-
What if you completely remove your shaper config?
-
-
I had this same problem with my AT&T microcell. Turn off packet scrubbing. Set your NAT rules to manual, and delete the default rule that is created for IPSec.
-
I had this same problem with my AT&T microcell. Turn off packet scrubbing. Set your NAT rules to manual, and delete the default rule that is created for IPSec.
Thanks, have tried the following:
- "Disable Firewall Scrub" is checked under Advanced > Firewall/NAT
- Set NAT mode to manual: no go
- Deleted default IPSec rules: no go
- Recreated default IPSec rules: still no go
Here are the rules I now have currently. This results in exactly the same packet capture / behaviour I documented initially (IKE 500/udp requests are being translated, ESP 4500/udp packets are not translated):
http://d.pr/i/17jSV
-
Some encouraging progress today.
One thing I should have mentioned initially is that the ISAKMP (4500/udp) packets are quite large (2032 bytes) and thus were being fragmented. After reading of some similar cases like mine on the forums, one of the suggestions was to set MSS clamping on the interfaces.
I've set the MSS on both the LAN and WAN to 1500 bytes and it now works!
There is still one problem though: it only works for one device. If I try connecting from a different device, it fails. Looking at the packet captures, traffic from the second device isn't being NATed at all. Traffic from the original / first device is NATed perfectly.
This appears to be NAT-related because if I reset states and initiate from the other device, it works while the other one doesn't. Essentially its "first in best dressed" and all other devices afterwards fail to NAT.
Any ideas on why it can only seem to handle / NAT one connection at a time?
-
Take the MSS out (it's not doing anything useful other than apparently forcing scrub on), and enable scrub. Then reset your states, and it should work after. Found what's most likely the source issue here, where you don't have scrub enabled, and have fragmented UDP traffic, it bypasses NAT on the egress interface. Gathering some more details to get a bug ticket opened.
-
@cmb:
Take the MSS out (it's not doing anything useful other than apparently forcing scrub on), and enable scrub. Then reset your states, and it should work after. Found what's most likely the source issue here, where you don't have scrub enabled, and have fragmented UDP traffic, it bypasses NAT on the egress interface. Gathering some more details to get a bug ticket opened.
I've removed the MSS clamping and switched on scrubbing. That seems to work as well as before; that is, I can establish a session from a single device but a second device fails to connect. Packet trace shows packets from the first device being NATed properly but packets from the second device still bypass NAT and vice-versa.
Let me know if there are any details I can provide.
Thanks so much for all your help so far.
-
Are you back to default auto outbound NAT as well?
Could you capture that traffic to a file and get me the pcap file? Can email that to me (cmb at pfsense dot org) with a link to this thread.
-
Bump, I'm seeing this too.. Sadly I need this working ASAP, so I'm reverting to a full 2.2.5 backup pre 2.2.6 taken on 2015/12/22 19:23:56 and see if this fixes it…
Will report back -
Was a ticket ever opened on this issue?
@cmb:
Found what's most likely the source issue here, where you don't have scrub enabled, and have fragmented UDP traffic, it bypasses NAT on the egress interface. Gathering some more details to get a bug ticket opened.
-
Sounds like it could possibly be https://redmine.pfsense.org/issues/5819 which is fixed on 2.3. I kind of doubt the referenced commit would apply cleanly against 2.2.x (again, assuming it's related) but it's worth checking for someone hitting the issue.
-
Sounds like it could possibly be https://redmine.pfsense.org/issues/5819 which is fixed on 2.3. I kind of doubt the referenced commit would apply cleanly against 2.2.x (again, assuming it's related) but it's worth checking for someone hitting the issue.
Nope, that's not it. I don't have two WANs.
-
Did you try it? Don't dismiss it outright because of that one difference.
-
Did I try what? I assume that fix is in the main code, and I'm running 2.2.6 I still periodically see this issue.
-
Look at the commit referenced on the ticket:
https://redmine.pfsense.org/projects/pfsense/repository/revisions/bc3e61c4950740128ef7d2200e6399ada2e0fae9/diff/src/etc/inc/filter.inc
Open up that file on your 2.2.x install and look for the stated lines and make similar edits.
