[strongSwan] IKEv1 and IKEv2 behavior for NAT-T in Strongswan

[SaRaVanAn]

Hi Friends,

    I have  few queries on IKEv1 and IKEv2 behavior in Strongswan for
NAT-T. It would he great, if you experts

help me out.


Please find the queries below

*
PC---------DSL_Modem------------Internet--------VPN_Server(StrongSwan).
*


Let us take IKEv1 first. Let us assume Mobike support is not available.

In this scenario, PC is using RemoteAccessClient (Say Cisco VPN Client) and
establishing a VPN connection with VPN_Server.

Assume NAT_T support is available in the VPN Client. i.e.PC will start
using port 4500 after the first packet is exchanged and ack is received
from VPN_Server (i.e.from 3rd packet in the flow).

The DSL_Modem will do NAT and let us assume that the global IP address used
by DSL Modem is “g1”.

Once if the connection is established, the VPN is logically established
between PC and VPN_Server. The DSL_Modem has no role in VPN connection
except the fact that the IP address seen by VPN_Server is given by
DSL_Modem.

Now, Assume that the VPN Peer dead detection timeout is too huge.

Now, if the link between DSL_Modem and service provider is flapping and if
DSL_Modem gets a new IP address say “g100” before DeadPeerDetection and
assume that DSL_Modem would have cleared the old NAT table (since the old
entries were using the old IP address “g1”).



Will this result in VPN disconnect?

Or, as per the IKEv1 RFC2409, and as per NAT_T RFCs (RFC3497 and RFC3498),
what is the expected behavior? Should it disconnect?



Moving to IKEv2, what is the expected behavior? Please note that MOBIKE
support is not there.

In RFC4306, section2.23 (NAT Traversal), says “In this case, this end
should allow dynamic update of the other ends IP address, as described
later.”

Does this mean that the dynamic update of the other ends IP address should
happen in VPN_Server without affecting the connection? FYI, we are not able
to understand which section is being referred by the phrase “as described
later” given in the above RFC statement.

Any clue?


Regards,

Saravanan N
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.strongswan.org/pipermail/users/attachments/20120405/6cd236c6/attachment.html>