[Openswan Users] Should be a simple routing question
Andy Gay
andy at andynet.net
Fri Aug 25 10:14:13 EDT 2006
On Fri, 2006-08-25 at 01:04 -0500, Greg Scott wrote:
> 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)."
Pretty much. "dir" here means "direction", not "direct" - it's matching
on incoming or outgoing packets. It works because (a) this policy is
more specific than the one Openswan sets, and (b) there are no actions
associated with the policy, so the traffic isn't processed further by
IPsec.
> 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.
That's because someplace in the startup scripts it does an "ip xfrm
policy flush".
I came up with the ip xfrm hack when I had the same problem as you a
long while back, I didn't know about passthrough conns then, and I've
not yet had time to investigate how they work, so I can't explain the
behavior you saw.
It's easy enough to do the ip xfrm thing as part of the normal updown
processing - add 'leftupdown=/etc/ipsec.d/my.updown' to your conn,
where /etc/ipsec.d/my.updown has:
#!/bin/sh
LOCALNET=10.15.1.0/24
/usr/local/lib/ipsec/_updown $*
if [ "$PLUTO_VERB" = "route-host" -o "$PLUTO_VERB" = "route-client" ]; then
for dir in in out; do
ip xfrm policy update dir $dir src $LOCALNET dst $LOCALNET
done
fi
>
> 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.
I agree. If you find out how to do that, please let us know!
>
> - 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