SNAT before IPSec, save my soul.

Adrian_Sanchez wrote:

> After digging through dozens of forums and asking for
help, I only got
> some comments about using the KLIPS module in order to
get back my
good'ol
> ipsec0 interface (but I had no chance to compile and
run it on Fedora
4
> and 5 with whatever from 2.6.5 to 2.6.15 kernels). I
also got comments
> about combining kernel 2.6.16, iptables 1.3.5 + POM in
a tainted,
> unspecific way my scorched brain can't figure out.

There is not iptables patches nor POM. The combination
is linux vanilla 2.6.16 & iptables 1.3.5. Nothing
else.

> Would you kindly point me into the right direction?

Draw your network schema.

_______________________________________________
Usersopenswan.org
http
://lists.openswan.org/mailman/listinfo/users
Building and Integrating Virtual Private Networks with
Openswan: 
http://www.amazon.com/gp/product/1904811
256/104-3099591-2946327?n=283155

if just  2.6.16 openswan and iptables 1.3.5 solves Adrian's
issues, PLEASE post the full config, etc,
cause i wanna know! don't keep that a secret!! 

-tl


On Fri, 24 Mar 2006 10:21:27 +0100
"Marco Berizzi" <pupillahotmail.com> wrote:

> Adrian_Sanchez wrote:
> 
> > After digging through dozens of forums and asking
for help, I only got
> > some comments about using the KLIPS module in
order to get back my
> good'ol
> > ipsec0 interface (but I had no chance to compile
and run it on Fedora
> 4
> > and 5 with whatever from 2.6.5 to 2.6.15 kernels).
I also got comments
> > about combining kernel 2.6.16, iptables 1.3.5 +
POM in a tainted,
> > unspecific way my scorched brain can't figure
out.
> 
> There is not iptables patches nor POM. The combination
> is linux vanilla 2.6.16 & iptables 1.3.5. Nothing
> else.
> 
> > Would you kindly point me into the right
direction?
> 
> Draw your network schema.
> 
> _______________________________________________
> Usersopenswan.org
> http
://lists.openswan.org/mailman/listinfo/users
> Building and Integrating Virtual Private Networks with
Openswan: 
> http://www.amazon.com/gp/product/1904811
256/104-3099591-2946327?n=283155
> 
_______________________________________________
Usersopenswan.org
http
://lists.openswan.org/mailman/listinfo/users
Building and Integrating Virtual Private Networks with
Openswan: 
http://www.amazon.com/gp/product/1904811
256/104-3099591-2946327?n=283155

> 
> There is not iptables patches nor POM. The combination
> is linux vanilla 2.6.16 & iptables 1.3.5. Nothing
> else.

Ok. I've just installed a fresh copy of Fedora Core 5,
which ships with:

- iptables 1.3.5
- kernel 2.6.15-1.2054_FC5
- OpenSWAN 2.4.4-1.1.2.1

Then I installed kernel 2.6.16-1.2069_FC5, which is still
under the 
"Test" branch, but did install and boot with no
problems at all.

I am trying to keep this as standard as possible, avoiding
any type of 
compiling, etc. Just a fresh OS and the additional 2.6.16
kernel rpm.


> 
> Draw your network schema.

My setup is very easy. Just imagine a simple IPSec tunnel
connecting two
private hosts. Well, I need my left private host to get into
the tunnel, 
but using one of my many OpenSWAN public IP address aliases:

192.168.0.4--200.0.0.1==140.0.0.1--140.0.0.2
              200.0.0.2

- 192.168.0.4 is my internal host.

- 200.0.0.1 is my IPSec gateway, it also has an IP alias of
200.0.0.2
which is reserved for my internal host via nat. In other
words, anyone 
can access 192.168.0.4 from the internet, by pointing at
200.0.0.2

- 140.0.0.1 is my remote ipsec gateway of which I have no
control
whatsoever. That's my ipsec peer which grants me access to
140.0.0.2:
presumably an internal, SNAT'ed host, too (but they're not
using Linux 
to do that... I've already asked).

Can you see what the problem is? I can't get 192.168.0.4 to
act like
200.0.0.2 before getting into the IPSec tunnel through
140.0.0.2

Now that I have a 2.6.16 kernel + iptables 1.3.5... will a
simple 
command like:

iptables -t nat -A POSTROUTING -s 192.168.0.4 -d 140.0.0.2
-j SNAT --to 
200.0.0.2

...actually SNAT the packets before they enter the tunnel in
the same box?

Or do I need to issue a more specific syntax for a rule to
do this?


Thanks!

_______________________________________________
Usersopenswan.org
http
://lists.openswan.org/mailman/listinfo/users
Building and Integrating Virtual Private Networks with
Openswan: 
http://www.amazon.com/gp/product/1904811
256/104-3099591-2946327?n=283155

Adrian R. Sanchez wrote:

>Can you see what the problem is? I can't get
192.168.0.4 to act like
>200.0.0.2 before getting into the IPSec tunnel through
140.0.0.2

This was a problem for linux kernel < 2.6.16rc

>Now that I have a 2.6.16 kernel + iptables 1.3.5... will
a simple command 
>like:
>
>iptables -t nat -A POSTROUTING -s 192.168.0.4 -d
140.0.0.2 -j SNAT --to 
>200.0.0.2
>
>...actually SNAT the packets before they enter the
tunnel in the same box?

Yes. Did you try?

>Or do I need to issue a more specific syntax for a rule
to do this?

You could also use the new 'policy match' to match packet
that are
subject to ipsec processing. It give you the same
functionality as
ipsecX devices.

>From man iptables:

policy
       This modules matches the policy used by IPsec for
       handling a packet.

       --dir in|out
              Used to select whether to match the policy
              used for decapsulation or the policy  that
              will  be  used  for  encapsulation.  in is
              valid in the PREROUTING, INPUT and FORWARD
              chains,  out  is valid in the POSTROUTING,
              OUTPUT and FORWARD chains.

       --pol none|ipsec
              Matches if the packet is subject to  IPsec
              processing.

       --strict
              Selects  whether to match the exact policy
              or match if any rule of the policy matches
              the given policy.

       --reqid id
              Matches  the reqid of the policy rule. The
              reqid  can  be  specified  with  setkey(8)
              using unique:id as level.

       --spi spi
              Matches the SPI of the SA.

       --proto ah|esp|ipcomp
              Matches the encapsulation protocol.

       --mode tunnel|transport
              Matches the encapsulation mode.

       --tunnel-src addr[/mask]
              Matches  the source end-point address of a
	      tunnel mode SA.  Only  valid  with  --mode
              tunnel.

       --tunnel-dst addr[/mask]
              Matches  the destination end-point address
              of a tunnel  mode  SA.   Only  valid  with
              --mode tunnel.

       --next Start the next element in the policy spec-
              ification. Can only be used with --strict


_______________________________________________
Usersopenswan.org
http
://lists.openswan.org/mailman/listinfo/users
Building and Integrating Virtual Private Networks with
Openswan: 
http://www.amazon.com/gp/product/1904811
256/104-3099591-2946327?n=283155

Be nice to have some examples of iptable "policy
match",
any resources, or any configs that can be directed to or
posted?

i didnt see any at iptables.org

-tl



On Fri, 24 Mar 2006 17:13:24 +0100
"Marco Berizzi" <pupillahotmail.com> wrote:

> Adrian R. Sanchez wrote:
> 
> >Can you see what the problem is? I can't get
192.168.0.4 to act like
> >200.0.0.2 before getting into the IPSec tunnel
through 140.0.0.2
> 
> This was a problem for linux kernel < 2.6.16rc
> 
> >Now that I have a 2.6.16 kernel + iptables 1.3.5...
will a simple command 
> >like:
> >
> >iptables -t nat -A POSTROUTING -s 192.168.0.4 -d
140.0.0.2 -j SNAT --to 
> >200.0.0.2
> >
> >...actually SNAT the packets before they enter the
tunnel in the same box?
> 
> Yes. Did you try?
> 
> >Or do I need to issue a more specific syntax for a
rule to do this?
> 
> You could also use the new 'policy match' to match
packet that are
> subject to ipsec processing. It give you the same
functionality as
> ipsecX devices.
> 
> >From man iptables:
> 
> policy
>        This modules matches the policy used by IPsec
for
>        handling a packet.
> 
>        --dir in|out
>               Used to select whether to match the
policy
>               used for decapsulation or the policy 
that
>               will  be  used  for  encapsulation.  in
is
>               valid in the PREROUTING, INPUT and
FORWARD
>               chains,  out  is valid in the
POSTROUTING,
>               OUTPUT and FORWARD chains.
> 
>        --pol none|ipsec
>               Matches if the packet is subject to 
IPsec
>               processing.
> 
>        --strict
>               Selects  whether to match the exact
policy
>               or match if any rule of the policy
matches
>               the given policy.
> 
>        --reqid id
>               Matches  the reqid of the policy rule.
The
>               reqid  can  be  specified  with 
setkey(8)
>               using unique:id as level.
> 
>        --spi spi
>               Matches the SPI of the SA.
> 
>        --proto ah|esp|ipcomp
>               Matches the encapsulation protocol.
> 
>        --mode tunnel|transport
>               Matches the encapsulation mode.
> 
>        --tunnel-src addr[/mask]
>               Matches  the source end-point address of
a
> 	      tunnel mode SA.  Only  valid  with  --mode
>               tunnel.
> 
>        --tunnel-dst addr[/mask]
>               Matches  the destination end-point
address
>               of a tunnel  mode  SA.   Only  valid 
with
>               --mode tunnel.
> 
>        --next Start the next element in the policy
spec-
>               ification. Can only be used with --strict
> 
> 
> _______________________________________________
> Usersopenswan.org
> http
://lists.openswan.org/mailman/listinfo/users
> Building and Integrating Virtual Private Networks with
Openswan: 
> http://www.amazon.com/gp/product/1904811
256/104-3099591-2946327?n=283155
> 
_______________________________________________
Usersopenswan.org
http
://lists.openswan.org/mailman/listinfo/users
Building and Integrating Virtual Private Networks with
Openswan: 
http://www.amazon.com/gp/product/1904811
256/104-3099591-2946327?n=283155

Just to confirm iptables 1.3.5 + Kernel 2.6.16 did the trick
regarding 
doing SNAT on the same VPN box.

It works like a charm.

Thanks for your valuable help!

-- 

Adrián R. Sanchez
Dpto. de Tecnología

Actionline de Argentina S.A.
Viamonte 570 (C1053ABL)
Buenos Aires, Argentina
Tel.: +54 11 5093-3905


_______________________________________________
Usersopenswan.org
http
://lists.openswan.org/mailman/listinfo/users
Building and Integrating Virtual Private Networks with
Openswan: 
http://www.amazon.com/gp/product/1904811
256/104-3099591-2946327?n=283155