<div dir="ltr">Hi All,<div><br></div><div>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. </div><div><br></div><div>regards,</div><div>SK</div><div><br></div><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Apr 20, 2015 at 11:31 PM, SM K <span dir="ltr"><<a href="mailto:sacho.polo@gmail.com" target="_blank">sacho.polo@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">Hi,<div><br></div><div>I have a few more questions on the NAT port detection. </div><div><br></div><div>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. </div><div><br></div><div>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. </div><div><br></div><div>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?</div><div><br></div><div>regards,</div><div>-SK</div></div><div class="HOEnZb"><div class="h5"><div class="gmail_extra"><br><div class="gmail_quote">On Fri, Apr 17, 2015 at 6:48 PM, SM K <span dir="ltr"><<a href="mailto:sacho.polo@gmail.com" target="_blank">sacho.polo@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">Thank you Martin, that was helpful.<div><br></div><div>cheers,</div><div>SK</div></div><div><div><div class="gmail_extra"><br><div class="gmail_quote">On Fri, Apr 17, 2015 at 12:34 AM, Martin Willi <span dir="ltr"><<a href="mailto:martin@strongswan.org" target="_blank">martin@strongswan.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi,<br>
<span><br>
> router changes its source port on the UDP encap packet midway through a<br>
> connection. I would like to look at this code to understand it a bit,<br>
> but I am having trouble identifying the exact point for IKEv1 where<br>
> this change is detected in the strongswan code.<br>
<br>
</span>The kernel backend fires a mapping() event on kernel_interface_t, which<br>
is propagated to all registered kernel_listener_t. libcharons<br>
kernel_handler_t is one of them, which raises an asynchronous<br>
migrate_job_t.<br>
<br>
That migrate job finds affected IKE_SAs and CHILD_SAs, tries to update<br>
them. If updating CHILD_SAs is not supported using MOBIKE, it rekeys<br>
them.<br>
<br>
Regards<br>
<span><font color="#888888">Martin<br>
<br>
</font></span></blockquote></div><br></div>
</div></div></blockquote></div><br></div>
</div></div></blockquote></div><br></div></div>