3 ms·

but the IKE wants to go from udp port 500 to udp port 500, even if they later agree on nat-t over udp 4500, so you can't have two boxes behind the nat answering

by IcePic 8y ago

but the IKE wants to go from udp port 500 to udp port 500, even if they later agree on nat-t over udp 4500, so you can't have two boxes behind the nat answering IKE connections, right? The flow can go outwards if one end is behind nat, but you can't have lots of ipsec-wanting clients behind same nat.

wahern 8y ago
The responder sends the reply to whichever address/port the initiator appears to be using. NAT-T is no different in this regard than any other protocol like HTTP, QUIC, WireGuard, etc. To be fair, it also suffers from the same issue as all of those: when a NAT gateway decides to remap the port (because it hasn't seen traffic in 30 seconds, because it got rebooted, w'ever) then traffic from the responder to the initiator is dropped. So the initiator has to constantly send keepalive messages so the responder has an up-to-date notion of where to send packets. The shorter the interval the more the wasteful traffic; the longer the interval then the more often you get frustrating delays. I've personally run into an issue where a stateful UDP gateway (downstream from the NAT gateway) had a 30s timeout on UDP flows. The IPSec initiator also sent NAT-T keepalives at 30s intervals. Because of drift and jitter, every few hours the 30s periods would synchronize so that the gateway dropped the state immediately before the next keepalive passed through, resulting in a very annoying 30s pause in activity. Most traffic was going from responder to initiator as the VPN was effectively a reverse proxy onto a corporate LAN, so one result was SSH sessions becoming unresponsive for 30s. To reiterate, there are no simple solutions to these sorts of problems.
bogomipz 8y ago
>"but the IKE wants to go from udp port 500 to udp port 500, even if they later agree on nat-t over udp 4500, so you can't have two boxes behind the nat answering IKE connections, right? " Not at all. The box handling IKE connection is not behind NAT it is in front of NAT, port 500 is on a public IP. Practically speaking it is usually the same box doing NAT and IPSEC. >"The flow can go outwards if one end is behind nat, but you can't have lots of ipsec-wanting clients behind same nat." No, that statement is completely false. The technique used is called "overloading", Cisco calls this PAT. It assigns a unique source port for each UDP or TCP session on the device doing the IPSEC termination.

by IcePic 8y ago

wahern 8y ago

The responder sends the reply to whichever address/port the initiator appears to be using. NAT-T is no different in this regard than any other protocol like HTTP, QUIC, WireGuard, etc. To be fair, it also suffers from the same issue as all of those: when a NAT gateway decides to remap the port (because it hasn't seen traffic in 30 seconds, because it got rebooted, w'ever) then traffic from the responder to the initiator is dropped. So the initiator has to constantly send keepalive messages so the responder has an up-to-date notion of where to send packets. The shorter the interval the more the wasteful traffic; the longer the interval then the more often you get frustrating delays. I've personally run into an issue where a stateful UDP gateway (downstream from the NAT gateway) had a 30s timeout on UDP flows. The IPSec initiator also sent NAT-T keepalives at 30s intervals. Because of drift and jitter, every few hours the 30s periods would synchronize so that the gateway dropped the state immediately before the next keepalive passed through, resulting in a very annoying 30s pause in activity. Most traffic was going from responder to initiator as the VPN was effectively a reverse proxy onto a corporate LAN, so one result was SSH sessions becoming unresponsive for 30s. To reiterate, there are no simple solutions to these sorts of problems.

bogomipz 8y ago

>"but the IKE wants to go from udp port 500 to udp port 500, even if they later agree on nat-t over udp 4500, so you can't have two boxes behind the nat answering IKE connections, right? " Not at all. The box handling IKE connection is not behind NAT it is in front of NAT, port 500 is on a public IP. Practically speaking it is usually the same box doing NAT and IPSEC. >"The flow can go outwards if one end is behind nat, but you can't have lots of ipsec-wanting clients behind same nat." No, that statement is completely false. The technique used is called "overloading", Cisco calls this PAT. It assigns a unique source port for each UDP or TCP session on the device doing the IPSEC termination.