[strongSwan] NAT mappings of ESP CHILD_SA changed !!!
Kesava Srinivas
keshavsrinu at gmail.com
Tue Aug 20 16:17:30 CEST 2013
Thank U for responding back.
<What's the point of changing the ports for certain traffic anyway?>
We are doing Policy Based routing in our Next Hop Router based on IP Header
Options. For the next hop router all the 5 tuple looks equal and hence we
are facing NAT Problems when routing a packet via a different interface
than the previous packet's routed interface (as U might be already knowing
the fact that NAT & CONN Track are tightly coupled modules). Once the
Kernel remembers the First Packet's 5 Tuple information and it's in/out
interfaces ., then for second packet ; it is trying to apply the same (NAT
IP). For that reason we want to have some metric in 5 tuple to differ and
looks like a different packet to the Next Hop Router's kernel. And
Obviously with out option the only one available was Source Port.
Well, I will try to patch the kernel_handler.c file but as U raised., still
need to see how it goes with the Kernel !!!
-Regards,
VKS.
On Tue, Aug 20, 2013 at 2:06 AM, Tobias Brunner <tobias at strongswan.org>wrote:
> Hi,
>
> > Looks like the Second Solution is Not working. Even though I configured
> > /etc/strongswan.conf with charon.keep_alive = 0 on both initiator and
> > responder, it looks like this configuration is Not reflecting at all.
> > Still I see Keep-alive Packets are going over Standard NAT-T Ports every
> > 10 seconds. (Initiator Strongswan - 5.0.1 & Receiver Strongswan - 5.1.0)
>
> That's because the change back to port 4500 is not caused by keepalive
> packets (which are silently ignored as they are not authenticated) but
> by DPD packets (check dpd... options in ipsec.conf). But any valid IKE
> packet could cause such a change.
>
> You may theoretically patch kernel_handler.c so that no update_sa_job is
> created when the kernel detects a changed NAT mapping for ESP packets.
> strongSwan would then ignore the changed ports and not update the SA.
> But I don't think this is optimal as the kernel will still create events
> for each received packet with a different port.
>
> What's the point of changing the ports for certain traffic anyway?
>
> Regards,
> Tobias
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.strongswan.org/pipermail/users/attachments/20130820/a4001622/attachment.html>
More information about the Users
mailing list