[strongSwan-dev] nat port change detection

[SM K]

Hi,

I have a few more questions on the NAT port detection.

If the NAT-T keep alive indicated a change in the source port of the
encapsulated UDP packets, would it trigger an update of the SA? I don't see
this happening. In fact, I dont see any logs when a nat-t keep alive is
received.

This is causing a a problem that I am seeing. I have a firewall connecting
to my strongswan after being NATted. Once the tunnels have been setup,
there is not much traffic on the ipsec tunnels and only nat-t keep alives
are being sent by the firewall. The router in the middle however changes
the source port of the udp packets sometime after the tunnels have been
established. Since there is no traffic on the ipsec tunnels, there are no
ESPs being exchanged. So there is no callback on the kernel listener to
indicate a NAT port change. Since strongswan still knows only about the old
port, it keeps sending DPDs to that port and eventually kills the tunnel
because there is no response from the firewall. This causes child SAs to be
also killed in strongswan, with out sending deletes to the firewall. So
now, firewall has SAs that strongswan doesn't and this breaks connectivity
to the clients behind the firewall.

Is there anyways that this can be worked around or fixed, so that the
firewall and strongswan do not go out of sync when the router in the middle
changes the port?

regards,
-SK

On Fri, Apr 17, 2015 at 6:48 PM, SM K <sacho.polo at gmail.com> wrote:

> Thank you Martin, that was helpful.
>
> cheers,
> SK
>
> On Fri, Apr 17, 2015 at 12:34 AM, Martin Willi <martin at strongswan.org>
> wrote:
>
>> Hi,
>>
>> > router changes its source port on the UDP encap packet midway through a
>> > connection. I would like to look at this code to understand it a bit,
>> > but I am having trouble identifying the exact point for IKEv1 where
>> > this change is detected in the strongswan code.
>>
>> The kernel backend fires a mapping() event on kernel_interface_t, which
>> is propagated to all registered kernel_listener_t. libcharons
>> kernel_handler_t is one of them, which raises an asynchronous
>> migrate_job_t.
>>
>> That migrate job finds affected IKE_SAs and CHILD_SAs, tries to update
>> them. If updating CHILD_SAs is not supported using MOBIKE, it rekeys
>> them.
>>
>> Regards
>> Martin
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.strongswan.org/pipermail/dev/attachments/20150420/406bb971/attachment.html>