From: Aidas Kasparas <a.kasparas@gmc.lt>
To: Dax Kelson <dax@gurulabs.com>
Cc: linux-net@vger.kernel.org, netdev@oss.sgi.com,
linux-kernel@vger.kernel.org
Subject: Re: 2.6.5, IPSec, NAT funnies
Date: Wed, 28 Apr 2004 09:55:17 +0300 [thread overview]
Message-ID: <408F5555.3080303@gmc.lt> (raw)
In-Reply-To: <1083133394.2817.40.camel@mentor.gurulabs.com>
Kernel bug. IPSec changes ip headers, but fails to say about this to
conntrack. More information
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=215980
Patch at
http://bugs.debian.org/cgi-bin/bugreport.cgi/ipsec_conntrack.diff?bug=215980&msg=3&att=1
As a workaround insert rule exemting ipsec traffic from masquerade:
iptables -t nat -I POSTROUTING 1 -p esp -j ACCEPT
Dax Kelson wrote:
> I have a 2.6 box doing IPSec and MASQUERADing that is borking up TCP
> port numbers of .
>
> /======IPSec ESP SA=====\
> [box1]-----------[fw1]-------Internet-------[fw2]-----------[box2]
> | / \ / \ |
> .5 10.1.0.1 StaticRealIP DHCPRealIP 10.200.1.1 .22
>
>
> fw1 = RHEL3 with latest official errata kernel (2.4+2.6ipsec)
> fw2 = Debian Sarge with 2.6.5-2 kernel from unstable
>
> IKE daemon is identical on both boxes -- current OpenSWAN CVS
>
> fw1 is SNATing the internal 10.1.0.0/16 network
> fw2 is MASQUERADing the internal 10.200.1.0/24 network
>
> iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE
>
> box2 sends a SYN packet to box1. It arrives OK at box1.
>
> source TCP port 33763, destination TCP port 3389
>
> So far so good.
>
> box1 sends back a SYN/ACK with TCP source port 3389 destination 32834.
> It leaves fw1 and arrives at fw2 on the external interface (eth0) and
> gets decrypted OK and unmodified.
>
> Here is the problem.
>
> When the SYN/ACK packet leaves fw2 out eth1 towards box2 the TCP source
> port has changed from the correct 3389 to the incorrect 1024. Box2
> naturally sends back an ICMP error message--handshake never completes.
>
> Packet capture details courtesy of tethereal...
>
> arriving and being decrypted on the fw2 external interface (eth0):
>
> 0.078883 a.b.c.d -> w.x.y.z ESP ESP (SPI=0x3bb63b4f)
> 0.078883 10.1.0.5 -> 10.200.1.22 TCP 3389 > 32834 [SYN, ACK] Seq=0
> Ack=1 Win=65535 Len=0 MSS=1460 WS=0 TSV=0 TSER=0
>
> leaving the fw2 internal interface (eth1) now borked with the source
> port changed to 1024:
> /-- error here
> 0.229413 10.1.0.5 -> 10.200.1.22 TCP 1024 > 32834 [SYN, ACK] Seq=0
> Ack=1 Win=65535 Len=0 MSS=1460 WS=0 TSV=0 TSER=0
>
> If I flush the nat table on fw2 then the borkage disappears and the TCP
> connection is properly established. The fw2 nat rule is simply this:
>
> iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE
>
> Another data point. TCP connections from fw2 itself into the remote
> network are fine.
>
> Dax Kelson
> Guru Labs
>
> -
> To unsubscribe from this list: send the line "unsubscribe linux-net" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
--
Aidas Kasparas
IT administrator
GM Consult Group, UAB
next prev parent reply other threads:[~2004-04-28 6:55 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2004-04-28 6:38 2.6.5, IPSec, NAT funnies Dax Kelson
2004-04-28 6:55 ` Aidas Kasparas [this message]
2004-04-28 17:45 ` Dax Kelson
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=408F5555.3080303@gmc.lt \
--to=a.kasparas@gmc.lt \
--cc=dax@gurulabs.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-net@vger.kernel.org \
--cc=netdev@oss.sgi.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).