From mboxrd@z Thu Jan 1 00:00:00 1970 From: Patrick McHardy Date: Fri, 12 May 2006 05:04:17 +0000 Subject: Re: [LARTC] SNAT on IPSEC tunnel with kernel 2.6/KAME tools? Message-Id: <44641751.2090909@trash.net> List-Id: References: <200605031322.30125.subscriptions@navig.ca> In-Reply-To: <200605031322.30125.subscriptions@navig.ca> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: lartc@vger.kernel.org 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//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