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.
regards, SK On Mon, Apr 20, 2015 at 11:31 PM, SM K <[email protected]> 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 <[email protected]> wrote: > >> Thank you Martin, that was helpful. >> >> cheers, >> SK >> >> On Fri, Apr 17, 2015 at 12:34 AM, Martin Willi <[email protected]> >> 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 >>> >>> >> >
_______________________________________________ Dev mailing list [email protected] https://lists.strongswan.org/mailman/listinfo/dev
