From: Alexander Samad <alex@samad.com.au>
To: netfilter@lists.netfilter.org
Subject: Re: SNAT and IPSEC
Date: Thu, 14 Apr 2005 15:05:56 +1000 [thread overview]
Message-ID: <20050414050556.GC29686@samad.com.au> (raw)
In-Reply-To: <425DB04D.4060304@riverviewtech.net>
[-- Attachment #1: Type: text/plain, Size: 1648 bytes --]
On Wed, Apr 13, 2005 at 06:50:37PM -0500, Taylor Grant wrote:
> >Couldn't he just SNAT the packets on his side when they become un-
> >encapsulated? I'm doing this on a couple of my vpn links.
>
> I don't think that you could just SNAT the packets that are on the way out
> because as I understand it SNAT happens in nat:POSTROUTING *after* the
> routing decision has been made. I had originally thought that the IPSec
> traffic did pass through IPTables a couple of times, once unencrypted and
> then again encrypted. But based on the LOG entries that he has presented
> the traffic only passes through IPTables one time on it's way out, and a
> couple of times on it's way in. Seeing as how the traffic is only passing
> through IPTables one time on it's way out, it is coming in to the system
> from the LAN and immediately going in to the IPSec stack and being
> encrypted and then sent out directly, leaving no chance for it to be SNATed
> before it enters the IPSec stack. Reportedly there are some kernel patches
> to fix this issues thus causing the packets to traverse IPTables twice,
> once unencrypted and once encrypted. If the packets did indeed pass
> through IPTables twice they could be SNATe
> d before they did enter the IPSec VPN. The only caveat would be that the
> IPSec VPN would have to be configured to allow traffic from the 10.3.3.x/24
> network vs his 10.2.2.x/24 network, this would have to be done on both ends
> too.
these pacthes exist in pom-ng and I believe have made it into 2.6.8 and
above (not sure about the entry version)
>
>
>
> Grant. . . .
>
>
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
next prev parent reply other threads:[~2005-04-14 5:05 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2005-04-12 18:08 SNAT and IPSEC Eduardo Spremolla
2005-04-12 19:11 ` Daniel Lopes
2005-04-13 12:01 ` Eduardo Spremolla
2005-04-13 14:26 ` Michael Muenz
2005-04-14 14:03 ` Daniel Lopes
2005-04-14 15:19 ` Eduardo Spremolla
2005-04-14 17:01 ` Jason Opperisano
2005-04-13 14:58 ` Jason Opperisano
2005-04-13 15:45 ` Eduardo Spremolla
2005-04-13 16:00 ` Daniel Lopes
2005-04-13 16:08 ` Daniel Wittenberg
2005-04-13 17:29 ` Eduardo Spremolla
2005-04-13 23:50 ` Taylor Grant
2005-04-14 5:05 ` Alexander Samad [this message]
2005-07-15 19:36 ` Trevor Cordes
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=20050414050556.GC29686@samad.com.au \
--to=alex@samad.com.au \
--cc=netfilter@lists.netfilter.org \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.