[strongSwan-dev] nat port change detection

SM K sacho.polo at gmail.com
Wed Apr 22 20:00:50 CEST 2015

Hi All,

During my testing, it seems that the kernel handler does get called all the
time when the port changes on the UDP encapsulated packets. I found it to
be called in 1 out of maybe 10 times. How do we handle NAT port changes?
See my question below.


On Mon, Apr 20, 2015 at 11:31 PM, SM K <sacho.polo at gmail.com> wrote:

> 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/20150422/61eb763a/attachment.html>

More information about the Dev mailing list