linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: "Mark E. Donaldson" <markee@bandwidthco.com>
To: "Scott Mcdermott" <smcdermott@questra.com>,
	<netfilter@lists.netfilter.org>, <linux-kernel@vger.kernel.org>
Subject: RE: SNAT interaction with kernel-based IPSEC (in 2.6)
Date: Thu, 4 Sep 2003 11:34:56 -0700	[thread overview]
Message-ID: <DKEDJAAMDCDBHFKPBEMPEEFNCIAA.markee@bandwidthco.com> (raw)
In-Reply-To: <20030904091525.GO17837@questra.com>

NAT and IPsec (depending on whether you are using AH or ESP) often do not
play well together.  I suspect your assumptions are correct on what is
occurring.  To solve this problem, I suggest you add a third interface on
your firewall and direct all IPsec packets out if it.  Non-IPsec packets
would then be allowed to go outbound (SNATTED) as normal. This would allow
you to effectively SNAT and use IPsec off the same firewall.

-----Original Message-----
From: netfilter-admin@lists.netfilter.org
[mailto:netfilter-admin@lists.netfilter.org]On Behalf Of Scott Mcdermott
Sent: Thursday, September 04, 2003 2:15 AM
To: netfilter@lists.netfilter.org; linux-kernel@vger.kernel.org
Subject: SNAT interaction with kernel-based IPSEC (in 2.6)


I'm having some difficulty doing simple pings over an IPSEC
tunnel using the implementation in 2.6.0-test4 (with
Racoon, and successful Phase 1 and 2, I get the IPSEC SA
fine), in combination with iptables.

I have SNAT rules on the same machine that is my IPSEC
tunnel endpoint.  I have RFC1918 IPs on my near side of the
NAT/IPSEC box, which are SNATted to routable IPs in the
normal case (where they don't go over the IPSEC tunnel) and
conntracked.  If they are destined for the remote LAN though
(at other end of tunnel), they need to go through
unmolested: I do NOT want them SNATted when they go over the
IPSEC tunnel, but to instead just bypass the `nat' table
altogether.  Is this possible? I would like them still to
traverse the `filter' table (so I can restrict the remote
LAN), but I would be happy right now if I could get just
bypass iptables altogether.

I am suspecting that when my packets do go over the tunnel,
get to the other end, and are unwrapped, they have the
translated IP as the source, and not the original RFC1918
source IP (which would then allow replies to get routed
correctly back over the IPSEC tunnel to me).  I am awaiting
a reply from the other end on whether or not my suspicion is
true, but in the meantime, I thought I would try to get an
understanding of how the kernel IPSEC implementation and
netfilter interact, and if it's even possible to do what I'm
trying to do (bypass nat rules in the case that the packet
is destined for the tunnel).  Hopefully this is a common
procedure that others have attempted already.

Thanks for any information.  Sorry to crosspost, I am not
sure where to discuss IPSEC issues that regard Netfilter.  I
tried subscribing to netdev, but it seems to just ignore my
subscription emails.



      parent reply	other threads:[~2003-09-04 18:36 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2003-09-04  9:15 SNAT interaction with kernel-based IPSEC (in 2.6) Scott Mcdermott
2003-09-04 11:15 ` Scott Mcdermott
2003-09-04 18:34 ` Mark E. Donaldson [this message]

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=DKEDJAAMDCDBHFKPBEMPEEFNCIAA.markee@bandwidthco.com \
    --to=markee@bandwidthco.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=netfilter@lists.netfilter.org \
    --cc=smcdermott@questra.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).