Carrier-grade NAT and mobile IKEv2
Hello everyone,
we have a lot of issues when users trying to connect to the Watchguard with mobile IKEv2, when they are sitting behind a CG-NAT. Most of the time the connection gets not established. The Watchguard Traffic Monitor shows reason="lifetime timer expires". I would say almost 5% of all users have this issue and it is getting more. Most of them are using Vodafone Germany as their ISP which is using CG-NAT for all new contracts. Currently you can call the support of the ISP and disable the CG-NAT option for free. But most users will not do that.
I know this might not be a specific Watchguard problem but I just want you to ask how your are handling this situation. I am planing to go back to mobile SSL VPN. This works without a problem on CG-NAT connections. But the Windows integration with IKEv2 allows us to connect to the Watchguard with the Windows login, which is nice for domain joined devices.
Do you guys have any solutions?
Comments
Hi @schwarzenbek
As far as I'm aware, the VPN should still work via CGNAT. It's likely there's something else that was changed that might be causing your issue (such as packet size or the ISP trying to curtail IKE connections for example.) I'd suggest opening a support case so that we can look into this and see if there's anything we can do to work around the issue.
-James Carson
WatchGuard Customer Support
I suspect some of our client's users will be in the "me too" camp in terms of CGNAT and mobile IKEv2 VPN connections - some of ours work fine here (Australia, New Zealand) and some don't work as well or at all.
While I suspect this
[https://watchguard.force.com/customers/wgknowledgebase?type=Known Issues&SFDCID=kA16S000000XeNxSAK&lang=en_US ] might be part of the problem, from what I can tell the carrier end is more often than not the issue (though we did have one user with double NAT on their home network behind a CGNAT...)
I'm wondering whether the DF bit option mentioned here [https://www.watchguard.com/help/docs/help-center/en-US/Content/en-US/Fireware/mvpn/ikev2/mvpn_ikev2_config_edit.html ] will help - problem I have is that our client [who has the problematic users/connections] can't give us a change window to test, and our internal setup doesn't have any users with issues.
Client is asking us to setup SSL VPN as an alternative, which they are testing at the moment.
The DF option sounds really interesting. If I am lucky I have the chance to test it at a client this week who sits behind a CG NAT and have this problem. I will post the results here. Thanks for the hint.
The user with the CG NAT did not called back yet. But I had a new user with the same issue. This user is not behind a CG NAT though. But what I could see from the Traffic Monitor it looked like the same issue (maybe I am wrong). I will post the logs separatly because they are to long.
I could fix the problem in a weird way.
First I have set the DF bit value to 1. The connection still failed. Than I have set the value to 2. Still failed. Than I set it back to the default value 0. But I did not test the connection immediatly after the change. Before I installed the SSL VPN client and established a connection over this way successfully. Disconnected the SSL VPN connection and tested the IKEv2 connection a last time. Well then the connection worked. I do not exactly know why but maybe this will help someone.
I will update the thread when the user with the CG NAT problem will call back.
Here is the full log:
https://pastebin.com/FYKVxFGH
After a lot of troubelshooting I was able to fix the issue.
The fragmented IKE_AUTH packets sended from the Windows client were bigger than 1500 bytes. It seems like some ISPs drop these packets.
The only solution for that is to lower the MTU size of the outgoing interface in Windows so the sended packets are lower than 1501 bytes.
For example: