IKEv2 / ISAKMP from iOS device behind pfSense / NAT-T not working
-
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.
-
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.
Cool! I'll give that a try. Is there any way to just download the new filter.inc file instead of making those edits by hand? I don't know the syntax of that file, and I don't want to screw it up.
The other thing is that I won't know for sure if it fixes the problem. It tends to come and go sporadically.
-
It wouldn't work directly since that commit was for pfSense 2.3, not 2.2.x. Would have to be adjusted by hand on 2.2.x.
-
Hello jimp,
i have the same problem in my 2.2.6 after update from 2.2.4.
Do i make the changes via built in editor from the gui? It must look like the green right file?
Greets
-
Just curious - if this is a known bug, why isn't it being addressed in 2.2?
-
Just curious - if this is a known bug, why isn't it being addressed in 2.2?
Because:
1. Nobody has yet confirmed the fix actually fixes this issue on 2.2.x
2. There are not likely to be any further 2.2.x releases with 2.3 being so close -
Found the solution today!
You only have to set a rule under firewall -> nat -> outbound that looks similar to the default rule for port 500. Of course with port 4500 and my lancom behind the pf can digger his tunnels ;D
Hope it helps other people!
