I don't know why, but for some reason it just didn't occur to me that
doing that would set the source IP but of course it would. Hand -> Face
slap! ;)
Thanks :)
On Fri 05 Jul 2013 11:51:39 BST, Todd T. Fries wrote:
Penned by Andy on 20130704 9:25.40, we have:
| On Thu 04 Jul 2013 15:22:55 BST, Anders Berggren wrote:
| >>I'd rather not have to create extra tunnels or define VPN policies with
subnets which have prefixes wider than the internal LANs.
| >>That leaves mangling, but I cannot see how I would do the mangling in PF to
make it work without doing a redirect through the loopback etc.. Just wondering if
anyone knows of a cleaner way?
| >
| >I think widening the flow's source is cleanest (as I mentioned in my first reply).
However, I think it's possible to use a gif tunnel for the tunnel encapsulation, and only
use IPsec for the endpoint encryption. It would probably work, because unlike IPsec flows,
it's not "source routed".
|
| Ah ha!!! Of course!! Thank you :D
|
| Andy.
The other option is to add a local route that seems pointless but actually aids
in the scenario.
Consider a router with an internal network IP of 192.168.0.1/24.
Consider a an IPSec tunnel from 192.168.0.0/24 <-> 192.168.1.0/24.
Consider adding a route 'route add 192.168.1.0/24 192.168.0.1'.
Suddenly the source IP of any daemon on the OpenBSD system becomes
192.168.0.1 when attempting to connect to any system on the
192.168.1.0/24 segment.
This trick only works for IPv4. For IPv6, there is no solution beyond
having each software choose its source address carefully.
FWIW.
