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
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