[LARTC] SNAT on IPSEC tunnel with kernel 2.6/KAME tools?

[LARTC] SNAT on IPSEC tunnel with kernel 2.6/KAME tools?

[G Georgiev]

	Hi,

	Could not conceive an working set-up for an IPSEC VPN made with racoon/setkey 
on which I have one address on my side acting as an SNAT router for all 
traffic from my network to a network segment on the far side. 

my network  --- my gateway  ---------------------- remote network
10.0.0.0/24  - 10.0.0.1 (10.253.0.2)  -- tunnel - 192.168.0.0/22

	All traffic starts on my side, so if I can SNAT/MASQUERADE packets to the 
tunnel address (10.253.0.2) it shall work. This would have been possible with 
FreeSwan, as it created network interfaces (ipsec0, ipsec1..), however with 
setkey there is no way of making it.
	
	The VPN starts on the gateway, simply all traffic destinate to 192.168.0.0/22 
should get an SNAT to 10.253.0.2 and go via the tunnel. SNAT however is 
available only in POSTROUTING chain, and no outgoing interface really exists 
with setkey.

	So, next rule should be implemented on the gateway: "Packets going to 
192.168.0.0/22 should be SNAT to 10.253.0.2 and go via the tunnel"

	Some ideas?

	Thanks, George.
_______________________________________________
LARTC mailing list
LARTC@mailman.ds9a.nl
http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc

Re: [LARTC] SNAT on IPSEC tunnel with kernel 2.6/KAME tools?

[Patrick McHardy]

G Georgiev wrote:
> 	Hi,
> 
> 	Could not conceive an working set-up for an IPSEC VPN made with racoon/setkey 
> on which I have one address on my side acting as an SNAT router for all 
> traffic from my network to a network segment on the far side. 
> 
> my network  --- my gateway  ---------------------- remote network
> 10.0.0.0/24  - 10.0.0.1 (10.253.0.2)  -- tunnel - 192.168.0.0/22
> 
> 	All traffic starts on my side, so if I can SNAT/MASQUERADE packets to the 
> tunnel address (10.253.0.2) it shall work. This would have been possible with 
> FreeSwan, as it created network interfaces (ipsec0, ipsec1..), however with 
> setkey there is no way of making it.
> 	
> 	The VPN starts on the gateway, simply all traffic destinate to 192.168.0.0/22 
> should get an SNAT to 10.253.0.2 and go via the tunnel. SNAT however is 
> available only in POSTROUTING chain, and no outgoing interface really exists 
> with setkey.
> 
> 	So, next rule should be implemented on the gateway: "Packets going to 
> 192.168.0.0/22 should be SNAT to 10.253.0.2 and go via the tunnel"
> 
> 	Some ideas?


Starting with 2.6.16 the kernel supports NAT with IPsec and includes
a "policy" match, which allows you to do similar things like
the "-o ipsec0" matching done with klips.


_______________________________________________
LARTC mailing list
LARTC@mailman.ds9a.nl
http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc

Re: [LARTC] SNAT on IPSEC tunnel with kernel 2.6/KAME tools?

[G Georgiev]

	Thanks,

	Will try out that - will upgrade the kernel and see how it works.

	George.


On Friday 05 May 2006 09:39 am, Patrick McHardy wrote:
> G Georgiev wrote:
> > 	Hi,
> >
> > 	Could not conceive an working set-up for an IPSEC VPN made with
> > racoon/setkey on which I have one address on my side acting as an SNAT
> > router for all traffic from my network to a network segment on the far
> > side.
> >
> > my network  --- my gateway  ---------------------- remote network
> > 10.0.0.0/24  - 10.0.0.1 (10.253.0.2)  -- tunnel - 192.168.0.0/22
> >
> > 	All traffic starts on my side, so if I can SNAT/MASQUERADE packets to
> > the tunnel address (10.253.0.2) it shall work. This would have been
> > possible with FreeSwan, as it created network interfaces (ipsec0,
> > ipsec1..), however with setkey there is no way of making it.
> >
> > 	The VPN starts on the gateway, simply all traffic destinate to
> > 192.168.0.0/22 should get an SNAT to 10.253.0.2 and go via the tunnel.
> > SNAT however is available only in POSTROUTING chain, and no outgoing
> > interface really exists with setkey.
> >
> > 	So, next rule should be implemented on the gateway: "Packets going to
> > 192.168.0.0/22 should be SNAT to 10.253.0.2 and go via the tunnel"
> >
> > 	Some ideas?
>
> Starting with 2.6.16 the kernel supports NAT with IPsec and includes
> a "policy" match, which allows you to do similar things like
> the "-o ipsec0" matching done with klips.
_______________________________________________
LARTC mailing list
LARTC@mailman.ds9a.nl
http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc

Re: [LARTC] SNAT on IPSEC tunnel with kernel 2.6/KAME tools?

[G Georgiev]

	Could you (or someone else on the list) just tell me how this can be done 
with the netfilter? I could not find a way for it. I am with kernel 2.6.16-14 
now. The problem, again:

 >     Could not conceive an working set-up for an IPSEC VPN made with
 > racoon/setkey on which I have one address on my side acting as an SNAT
 > router for all traffic from my network to a network segment on the far
 > side.
 >
 > my network  --- my gateway  ---------------------- remote network
 > 10.0.0.0/24  - 10.0.0.1 (10.253.0.2)  -- tunnel - 192.168.0.0/22
 >
 >     The VPN starts on the gateway, simply all traffic destinate to
 > 192.168.0.0/22 should get an SNAT to 10.253.0.2 and go via the tunnel.
 > SNAT however is available only in POSTROUTING chain, and no outgoing
 > interface really exists with setkey.

 >     So, next rule should be implemented on the gateway: "Packets going to
 > 192.168.0.0/22 should be SNAT to 10.253.0.2 and go via the tunnel"

	George.

_______________________________________________
LARTC mailing list
LARTC@mailman.ds9a.nl
http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc

Re: [LARTC] SNAT on IPSEC tunnel with kernel 2.6/KAME tools?

[G Georgiev]

       OK,

        Found a solution - if some is interested - assigned the near end of 
the IPSEC tunnel address to the internal interface; this way got a 
POSTROUTING chain available and did an SNAT there:

ip addr add 10.253.0.2 dev eth0;
ip route add to unicast 192.168.4.0/24 via 10.253.0.2
iptables -t nat -A POSTROUTING -d 192.168.4.0/24 -j SNAT --to 10.253.0.2

        Looks to work just fine, despite being not so 'clean' - I would prefer 
to have a separate interface for the VPN, not to assign an alias to eth0. 
Does not work with lo instead of eth0.

        George.

On Thursday 11 May 2006 11:01 am, G Georgiev wrote:
> 	Could you (or someone else on the list) just tell me how this can be done
> with the netfilter? I could not find a way for it. I am with kernel
> 2.6.16-14
>
> now. The problem, again:
>  >     Could not conceive an working set-up for an IPSEC VPN made with
>  > racoon/setkey on which I have one address on my side acting as an SNAT
>  > router for all traffic from my network to a network segment on the far
>  > side.
>  >
>  > my network  --- my gateway  ---------------------- remote network
>  > 10.0.0.0/24  - 10.0.0.1 (10.253.0.2)  -- tunnel - 192.168.0.0/22
>  >
>  >     The VPN starts on the gateway, simply all traffic destinate to
>  > 192.168.0.0/22 should get an SNAT to 10.253.0.2 and go via the tunnel.
>  > SNAT however is available only in POSTROUTING chain, and no outgoing
>  > interface really exists with setkey.
>  >
>  >     So, next rule should be implemented on the gateway: "Packets going
>  > to 192.168.0.0/22 should be SNAT to 10.253.0.2 and go via the tunnel"
>
> 	George.
>
> _______________________________________________
> LARTC mailing list
> LARTC@mailman.ds9a.nl
> http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
_______________________________________________
LARTC mailing list
LARTC@mailman.ds9a.nl
http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc

Re: [LARTC] SNAT on IPSEC tunnel with kernel 2.6/KAME tools?

[Patrick McHardy]

G Georgiev wrote:
>        OK,
> 
>         Found a solution - if some is interested - assigned the near end of 
> the IPSEC tunnel address to the internal interface; this way got a 
> POSTROUTING chain available and did an SNAT there:
> 
> ip addr add 10.253.0.2 dev eth0;
> ip route add to unicast 192.168.4.0/24 via 10.253.0.2
> iptables -t nat -A POSTROUTING -d 192.168.4.0/24 -j SNAT --to 10.253.0.2
> 
>         Looks to work just fine, despite being not so 'clean' - I would prefer 
> to have a separate interface for the VPN, not to assign an alias to eth0. 
> Does not work with lo instead of eth0.

A few hints:

- lo doesn't work because IPsec is disabled by default on loopback.
  Check /proc/sys/net/ipv4/conf/<dev>/disable_{policy,xfrm}. If
  you disable rp_filter you can even route the IPsec network to
  lo and it will work (or use dummy if working with a seperate
  interface makes it easier for your).
- you don't need the extra address and route, just SNAT is enough
- The policy match can be used to express something similar to
  "-i ipsec0" and "-o ipsec0".
_______________________________________________
LARTC mailing list
LARTC@mailman.ds9a.nl
http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc