[strongSwan-dev] nat port change detection
sacho.polo at gmail.com
Wed Apr 22 20:00:50 CEST 2015
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:
> 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
> 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?
> On Fri, Apr 17, 2015 at 6:48 PM, SM K <sacho.polo at gmail.com> wrote:
>> Thank you Martin, that was helpful.
>> On Fri, Apr 17, 2015 at 12:34 AM, Martin Willi <martin at strongswan.org>
>>> > 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
>>> 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
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Dev