[Openswan Users] Should be a simple routing question

Greg Scott GregScott at InfraSupportEtc.com
Fri Aug 25 02:04:39 EDT 2006


Trying this conn:

conn pass-localstuff
        left=10.15.1.1
        right=0.0.0.0
        rightsubnet=10.15.1.0/24
        auto=route
        authby=never
        type=passthrough

that Paul suggested did not change the routing.  Local traffic still
tries to use the tunnel.  I noticed this line in /var/log/secure when I
restarted ipsec:

Aug 24 22:50:27 roseville-fw pluto[27999]: "pass-localstuff": cannot
route connection without knowing our nexthop

So I tried putting in a leftnexthop, like this:

conn pass-localstuff
	left=10.15.1.1
	leftnexthop=10.15.1.1
	right=0.0.0.0
	rightsubnet=10.15.1.0/24
	auto=route
	authby=never
	type=passthrough
  
This did not help.  In fact, ipsec did not even set up a conn named
pass-localstuff.  It's as if that conn definition was essentially a
noop.  It must be illegal for left and leftnexthop to be the same IP
Address.  

So I tried this hack:

/sbin/ip addr add 10.15.1.2/24 broadcast 10.15.1.255 dev eth1

And modified the conn above to look like this:

conn pass-localstuff
	left=10.15.1.1
	leftnexthop=10.15.1.2
	right=0.0.0.0
	rightsubnet=10.15.1.0/24
	auto=route
	authby=never
	type=passthrough

Now I can ping hosts in 10.15.1.0/24 but I don't like having to hack a
2nd IP Address on the inside interface.  

I also tried this conn:

conn pass-localstuff
	left=10.15.1.1
	leftsubnet=10.15.1.0/24
	right=0.0.0.0
	rightsubnet=10.15.1.0/24
	auto=route
	authby=never
	type=passthrough

I see this ugly message again in /var/log/secure:

Aug 25 00:33:36 roseville-fw pluto[31659]: "pass-localstuff": cannot
route connection without knowing our nexthop

Pings don't reply and traceroute to the local subnet goes through the
tunnel.  Bummer!

So I'll try Andy's ip xfrm suggestion.  I'm kind of afraid of that one
because I don't completely understand what ip xfrm does.  But if I
waited until I understood everything to try it, I guess I would still be
living with my parents.  :)

So I took out the conn definition above, restarted ipsec, and tried this
instead:

 /sbin/ip xfrm policy show > before.tmp

 /sbin/ip xfrm policy add dir in src 10.15.1.0/24 dst 10.15.1.0/24 

 /sbin/ip xfrm policy add dir out src 10.15.1.0/24 dst 10.15.1.0/24

 /sbin/ip xfrm policy show > after.tmp

 diff before.tmp after.tmp
0a1,2
> src 10.15.1.0/24 dst 10.15.1.0/24 
>       dir in priority 0 
4a7,8
> src 10.15.1.0/24 dst 10.15.1.0/24 
>       dir out priority 0 

The above syntax must mean, "Everyting inbound with source 10.15.1.0/24
and destination 10.15.1.0/24 should route dir(ect).'  And similarly,
"Everyting outbound with source 10.15.1.0/24 and destination
10.15.1.0/24 route dir(ect)."

This worked - pings answered and traceroute to the local subnet works as
expected.  I also noticed that restarting ipsec must change those ip
xfrm settings back to their default values, because when I restarted
IPSEC again, local pings stopped answering and traceroutes to the local
subnet went through the tunnel again.  So these commands need to run
after every ipsec restart.

I still would love to see a conn definition that did this without adding
a 2nd IP Address to the internal NIC.  This would be much cleaner and
the whole thing would be self-contained.

- Greg Scott



-----Original Message-----
From: users-bounces at openswan.org [mailto:users-bounces at openswan.org] On
Behalf Of Paul Wouters
Sent: Tuesday, August 22, 2006 1:48 PM
To: Andy Gay
Cc: users at openswan.org; Greg Scott
Subject: Re: [Openswan Users] Should be a simple routing question

On Tue, 22 Aug 2006, Andy Gay wrote:

> > Left 10.15.1.0/24 <------> Right 10.0.0.0/8.
> >      Site B                      Site A
> >
> > The tunnel works great - both sides see each ohter just fine, thanks

> > to lots of help from people in this list.
> >
> > Here's the issue.  When I traceroute from the siteB router at 
> > 10.15.1.1 to anything else in SiteB, it tries to route via SiteA!  
> > Very strange indeed!
> >
> > Well, it kind of makes sense because my tunnel definition evidently 
> > told it to behave this way.  I was wondering if there is a way to 
> > make the local route happen before the tunnel route?
>
> I don't think this is a routing issue, it's to do with IPsec policy.
> Your policy says anything with source address 10.15.1.0/24 and 
> destination 10.0.0.0/8 should be sent through the tunnel.
>
> Try doing this on the siteB router:
>
> ip xfrm policy add dir in src 10.15.1.0/24 dst 10.15.1.0/24 ip xfrm 
> policy add dir out src 10.15.1.0/24 dst 10.15.1.0/24
>
> That will add some more specific policies for local traffic.
>
> I believe there's a way to do that using a passthrough conn as well, 
> I'm not certain about the syntax for that.

try:

conn pass-localstuff
        left=10.15.1.1
        right=0.0.0.0
        rightsubnet=10.15.1.0/24
        auto=route
        authby=never
        type=passthrough

Paul
_______________________________________________
Users at openswan.org
http://lists.openswan.org/mailman/listinfo/users
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