[prev in list] [next in list] [prev in thread] [next in thread] 

List:       vpn
Subject:    [VPN] Re: local processes and tunnels
From:       "Russell Howe" <rhowe () siksai ! co ! uk>
Date:       2006-01-05 1:16:23
Message-ID: 20060105011623.GA17293 () xiao ! rsnet
[Download RAW message or body]

On Wed, Jan 04, 2006 at 08:43:33PM +1100, Neale Banks wrote:
> One for the IPSec tunnel-wizardary department - but first some
> ascii-art:
> 
>             ----------                     -------------
> 	   |          |     Wireless      |             |
> 	   | Leaf-Svr |-------------------| Central-Svr |
> 	   |          |                   |             |
> 	   |          | == == == == == == |             |
> 	   |          | Tunnel (Openswan) |             |
>             ----------                     -------------
> 	         |                                |
> 	 Leaf-LAN|                     Central-LAN|
>            |----------|                   |-------------|
> 	     |                                |
> 	     |Client                          |NS
> 	   -----                            -----
> 	  |     |                          |     |
> 	  |     |                          |     |
> 	   -----                            -----
> 
> As I hope the diagram suggests, there's a remote site (leaf-node) linked
> back to a central site via an Openswan tunnel over a wireless link.
> Leaf-Svr and Central-Svr are running Fedora (Openswan and kernel 2.6).
> 
> Clients can happily communicate via the tunnel to nodes on the
> Central-LAN.  So far, so good.  But... not so good for processes on
> Leaf-Svr (e.g. name resolver querying the name-server on
> Central-LAN("NS")) - we'd like them to communicate with nodes on
> Central-LAN via the tunnel. Not unreasonably, these packets are not
> encapsulated in the tunnel as they originate from the address of the
> wireless-side.
> 
> I tried putting an iptables rule in the POSTROUTING chain of the nat
> table to SNAT name requests to come from Leaf-Svr's Leaf-LAN interace
> address, but no cigar.
> 
> Any other suggestions?

I suspect packets are being generated with the wrong source address for
the tunnel policy.. either create a second tunnel of
Leaf-Svr-Wireless-address <===> Central-LAN, or use iproute2's policy
routing to do something like:

ip route add central-LAN via Central-Svr src Leaf-Svr-Leaf-LAN-Address

So, if...

Leaf-LAN	10.0.0.0/24
Central-LAN	172.16.0.0/24
wireless LAN	192.168.0.0/24
Leaf-Svr	10.0.0.1 on Leaf-LAN
Leaf-Svr	172.16.0.1 on the Wireless LAN
Central-Svr	192.168.0.2 Wireless LAN

... you'd do something like this:

ip route add 172.16.0.0/24 via 192.168.0.2 src 10.0.0.1

By default, you would have had something like this, I bet:

ip route add 172.16.0.0/24 via 192.168.0.2 src 192.168.0.1 (the src <x>
bit being implicit).

You should be able to set that route and see if it magically fixes
things. If it does, then I probably have a replacement set of updown
scripts which you'll find useful.

I hope the above is clear...

-- 
Russell Howe       | Why be just another cog in the machine,
rhowe@siksai.co.uk | when you can be the spanner in the works?
_______________________________________________
VPN mailing list
VPN@lists.shmoo.com
http://lists.shmoo.com/mailman/listinfo/vpn
[prev in list] [next in list] [prev in thread] [next in thread]