[Openswan Users] Help required - routing ipsec (native Kernel 2.6) on a multi-homed host?

Alex Ip user001 at eatsrootsandleaves.com
Fri Nov 9 19:08:07 EST 2007


G'day Paul...

	Thanks heaps for getting back to me, but I'm really not sure that a
passthrough definition will help me here. The issue I have is more one of
routing *outside* the VPN using only the public IP addresses of the machines
concerned. At the moment, I can't get the encrypted VPN packets to go out
the correct interface unless I explicitly specify that ALL packets destined
for the public IP addresses of the other VPN nodes (both encryped and
unencrypted) should be routed via the second interface (ppp1), while the
default route to everything else on the internet is left to go via the other
interface (ppp0). Is there any analogue of the klips
interfaces="ipsec0=ppp1" directive to force all VPN traffic via a particular
interface? That's all I really want to do - I believe the problems I am
experiencing are a direct consequence of having non-VPN replies to the
remote machines going out via a different interface to the one on which they
arrived.

	In a nutshell, I would prefer not to have to override the default
routing for anything, but instead tell ipsec to send/receive the encrypted
packets on a different interface. Is it possible to do this with the native
2.6 stack? I should also mention a complication in that the next hop for
each of the two pppoe interfaces is dynamic and is sometimes the same
between the two, so overriding the ipsec leftnexthop/rightnexthop definition
doesn't help me.

Thanks again,

Alex.

-----Original Message-----
From: Paul Wouters [mailto:paul at xelerance.com] 
Sent: Friday, 9 November 2007 1:55 AM
To: Alex Ip
Cc: users at openswan.org
Subject: Re: [Openswan Users] Help required - routing ipsec (native Kernel
2.6) on a multi-homed host?

On Thu, 8 Nov 2007, Alex Ip wrote:

>	I have a local VPN node with two pppoe ADSL links to the internet.
> I am trying to segregate the VPN traffic from the general internet traffic
> (e-mail, porn, surfing etc.) and the only way I've been able to do this is
> by overriding the default route for all of the remote VPN nodes (each with
> a single internet-connected interface) so that all of their outbound
> traffic goes via the designated VPN-specific interface (ppp1). This works
> quite nicely, but, unfortunately, it seems to create problems at the other
> nodes with some protocols when they try to connect to the local node via
> the general interface (ppp0) presumably because the return path is via the
> VPN-specific interface (ppp1). For example, pings from the remote nodes to
> the VPN interface work quite happily, but they fail when directed to the
> general interface. The most pressing problem is that SMTP fails from the
> remote nodes and there is apparently no easy way for me to direct that
> traffic to the VPN interface instead of the default general one.

> 	Can anyone suggest a nicer way for me to put all ipsec traffic on
one 
> interface using the native 2.6 kernel ipsec stack while leaving 
> everything else (preferably including the unencrypted node-node 
> traffic) on the other? It looks like I can force ipsec to use a 
> particular interface if I use Klips, but I am trying to avoid having 
> to install and maintain Klips if I can help it. Note that ipsec works 
> just fine so long as the routing is set up correctly beforehand. I 
> hope I've explained the problem clearly enough - thanks in anticipation.

You an can create passthrough connections, something like (untested):

conn passthrough1
	left=yourip
	leftsubnet=yoursubnet/mask
	right=0.0.0.0
	rigtsubnet=0.0.0.0/0
	# email
	rightprotoport=6/25
	authby=never
	auto=route

It will be a bit trick for random high ports (as %any will cause other
problems), so you will have to try and play around with these for a bit.
(Or just use a right=ip.of.mail.server instead)

Paul
--
Building and integrating Virtual Private Networks with Openswan:
http://www.amazon.com/gp/product/1904811256/104-3099591-2946327?n=283155



More information about the Users mailing list