Build 2422: IPsec NAT-T passthrough - WAN n error

This is not new in b2422 - but I have only just now sat down to sort it out. Balance 30.

Setup:

outbound policy says all traffic to go out WAN 2 (or 3).
network -> Service passthrough -> IPsec NAT-T set to enable, and default ports.

problem: Peplink always does the initial IPsec NAT-T on WAN 1, and ignores outbound policy rules, but then follows the rules later on, and breaks the connection due to WAN n change.

example:

Client starts IPSec/L2TP connection;

Client sends out initial port 500 UDP keysetup packets. Error Starts here: Peplink should send this per outbound policy rule (WAN2), but ignores that and ALWAYS sends initial port 500 packets on WAN 1 every time.

The key exchange succeeds, despite being on wrong WAN.

Client sends out second part exchange now on port 4500 UDP. Error goes fatal: Peplink now does observe Outbound policy rule (WAN2). But the server ends now sees one session split over two IP’s, and it fails.

IPsec NAT-T is like a hidden outbound policy rule that uses the persistence algorithm. It is enabled by default to keep UDP 500 and UDP 4500 on the same WAN link for the same user so that the user does not alternate WAN links when establishing a client VPN. Since this works like the persistence algorithm, it is not certain which WAN link will be used. Simply disable IPsec NAT-T and you can control this traffic with outbound policy rules instead.

Hi Ron,

Thanks for that description. My research shows it does not follow the persistence for the session. Yes it does hold all port 500 onto one WAN, but it does not follow the “session”, and the change to port 4500 will move to another WAN.

It seems it needs a rule that has persistence based on source IP, but also to observe outbound policy first for WAN selection, which it currently ignores.

I don’t think I can make a policy rule that says; port 500 and 4500 only. I can make rules with a single port, or a port range, but not two separated port #.

Currently, with only IPsec NAT-T Passthrough enabled, all UDP port 500 and UDP port 4500 will be routed as priority from WAN1 and so on. If WAN1 failed, WAN2 will be used and so on. And this will override Outbound Policy.

In your situation, if you want to route UDP 500 and 4500 to WAN2, you can disable IPsec NAT-T Passthrough and add two priority Outbound Policy, for UDP 500 and UDP 4500 to go across WAN2.

But it does not currently work that way. The first part of the session to port 500 will follow your description, and then the second part of the session to port 4500 will follow the outbound policy rules.

So the current situation is being split between your fixed rule and the outbound policy rule - nothing works properly.

Would you please use a IPsec client to connect the server? When you got the error message from client, obtain the diagnostic report immediately and submit here.

Here we are using a Windows client to connect to a Windows VPN server, via an IPsec/L2TP connection. The connection never succeeds. The port 500 part of the session, always runs on WAN1, and the port 4500 part, follows the outbound rules which is a different WAN, and it never succeeds to connect.

rossh_pl did you open a support ticket on this yet?
Thanks -Tim

I thought this was the feedback forum? You can’t fix things on your own?

Of course we fix things on our own, but sometimes it is a quicker process when we can get the diagnostic report from our beta testers such as yourself.

The issue would appear to be in the code design of the device. If you need a test Windows VPN account, then contact me offline.