Hi,
while doing a test set-up I'm coming back to a similar issue:
I have an IPSEC tunnel, connecting 2 IPv6 networks (LAN1 and LAN2):
+---+ +---+ +---+ +---+
| A +-- LAN1 --+ B +-- IPSEC --+ C +-- LAN2 --+ D |
+---+ +-+-+ +-+-+ +---+
------------
flow esp in from fda3:bdf5:7e29:1::/64 to fda3:bdf5:7e29:2::/64 \
peer 10.0.2.1 srcid client dstid gw type use
flow esp out from fda3:bdf5:7e29:2::/64 to fda3:bdf5:7e29:1::/64 \
peer 10.0.2.1 srcid client dstid gw type require
------------
On both tunnel ends, routing to the remote net does not work.
I'm announcing the remote prefix via rtadvd on both LANS and
receive traffic from A/D, directed to remote net at B/C.
Neither B nor C forward this traffic to the tunnel.
Like in the default route case, I have at B/C a static route to
the remote net pointing at localhost.
Does it matter that there is no IPv6 default route at all
in this setup?
What can I do to get the routing work?
Am 20.12.2010 um 17:23 schrieb Stuart Henderson:
On 2010/12/20 13:12, Axel Rau wrote:
Hi all,
besides some other, I have these ipsec routes on my (routing) CARPed
tunnel endpoint pair (netstat -rn):
OpenBSD's IPsec implementation (like most of the earlier
implementations) exclusively uses flows rather than route table
entries. As they aren't in the routing table at all, you can't
redistribute them from there into routing protocols as you'd
like to do.
You could either add a dummy default route (iirc even a blackhole
route should be fine e.g. route add -inet6 localhost -blackhole)
and announce that into your routing protocols (the traffic would
still get matched by this flow assuming the source address is
ok). Otherwise you'll have to do something like gre-over-ipsec
so you can get a real route table entry.
Axel
---
PGP-Key:29E99DD6 b +49 151 2300 9283 b computing @ chaos claudius
