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

[Kesava Srinivas]

HI Tobias,
Can u please look in to this in your free time !!!

-Thnx,
VKS.


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

> 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/20130818/a6572b6d/attachment.html>