[strongSwan] NAT mappings of ESP CHILD_SA changed !!!

[Kesava Srinivas]

Tobias,

Also, FYI:

Looks like the Second Solution is Not working. Even though I configured
/etc/strongswan.conf with charon.keep_alive = 0 on both initiator and
responder, it looks like this configuration is Not reflecting at all. Still
I see Keep-alive Packets are going over Standard NAT-T Ports every 10
seconds. (Initiator Strongswan - 5.0.1 & Receiver Strongswan - 5.1.0)

Please let me know if there is any other way to control this !!!

Thanks for your Time.

-Best Regards,
VKS.


On Thu, Aug 15, 2013 at 8:48 AM, Kesava Srinivas <keshavsrinu at gmail.com>wrote:

> Thanks Tobias for the response.
>
> Yes. Your Guess was Correct. For the Control traffic , still the standard
> Ports remains same (4500-4500). No Source Port Change for them. This NAT
> Mapping was happening only for specific Traffic (Ex: ssh,http,ftp etc) . We
> have a Kernel space Module written on Router (linux machine) to identify
> the SSH Traffic (using iptables Mark etc.. ) and then over writing the
> NAT-T header's source port from 4500 to 1003.
>
> Now inorder to handle this scenario where Control Traffic (Keep-alives)
> will still go over 4500-4500 and Data Traffic will have a source port
> change , whats the possible tweak that we can do in strongswan or Linux
> kernel !!! Thinking of two feasible solutions here...
>
> 1] Can't it handle parallely both the Traffic ? 1]4500-4500 2]1003-4500
> 2] Controlling the keepalives to be delayed further (from 10secs to some
> 40-50 secs) in such a way that meanwhile communcation happens with Port
> 1003.
>
> Please let me know of any more solutions to handle this scenario in the
> best way!!!
>
> -Best Regards,
> VKS.
>
>
> On Thu, Aug 15, 2013 at 2:04 AM, Tobias Brunner <tobias at strongswan.org>wrote:
>
>> Hi,
>>
>> > Does that mean., Target Router's strongswan not handling this Changed
>> > packet correctly ?
>>
>> No, the daemon correctly updates the two SAs:
>>
>> > Aug 14 18:55:23 01[KNL] NAT mappings of ESP CHILD_SA with SPI c22c81c5
>> and reqid {1} changed, queuing update job
>> > ...
>> > Aug 14 18:55:23 10[KNL] updating SAD entry with SPI c22c81c5 from
>> 192.168.3.128[4500]..10.10.0.130[4500] to
>> 192.168.3.128[1003]..10.10.0.130[4500]
>> > ...
>> > Aug 14 18:55:23 10[KNL] updating SAD entry with SPI c41a180e from
>> 10.10.0.130[4500]..192.168.3.128[4500] to
>> 10.10.0.130[4500]..192.168.3.128[1003]
>>
>> But the problem is that after the update an IKE packet is actually
>> received from port 4500, not 1003, which reverts those updates:
>>
>> > Aug 14 18:55:32 11[NET] received packet: from 192.168.3.128[4500] to
>> 10.10.0.130[4500] (76 bytes)
>> > ...
>> > Aug 14 18:55:32 11[KNL] updating SAD entry with SPI c22c81c5 from
>> 192.168.3.128[1003]..10.10.0.130[4500] to
>> 192.168.3.128[4500]..10.10.0.130[4500]
>> > ...
>> > Aug 14 18:55:32 11[KNL] updating SAD entry with SPI c41a180e from
>> 10.10.0.130[4500]..192.168.3.128[1003] to
>> 10.10.0.130[4500]..192.168.3.128[4500]
>>
>> And such packets continue to arrive from port 4500:
>>
>> > Aug 14 18:55:42 12[NET] received packet: from 192.168.3.128[4500] to
>> 10.10.0.130[4500] (76 bytes)
>>
>> So how exactly did you force the change of the NAT mapping?  It seems it
>> doesn't apply to all the traffic.
>>
>> Regards,
>> Tobias
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.strongswan.org/pipermail/users/attachments/20130815/f66f2159/attachment.html>