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?

For situations like this what would be really handy is a diagram of
where the various netfilter chains fit together combined with where
IPSec encapsulates packets (e.g. to show if netfilter's POSTROUTING
chain of the nat table comes before or after encapsulation). Any
pointers to such a diagram, or even a description?

Thanks,
Neale.

_______________________________________________
VPN mailing list
VPN@lists.shmoo.com
http://lists.shmoo.com/mailman/listinfo/vpn