/etc/ipsec.d/examples/hub-spoke.conf is in openswan 1:2.6.37-1.
This file is owned by root:root, with mode 0o644.
The actual contents of the file can be viewed below.
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 | # If you are using a hub-spoke scenario with NETKEY, you run into a
# problems with ipsec policies because netkey overrides routes by design.
# Example: Your head office is 10.0.0.0/8. Your branch offices
# are all ranges taken from there, eg office1 is 10.0.1.0/24, office2 is
# 10.0.2.0/24. etc
Your subnet conn will be something like:
conn office1-headoffice
left=someip
leftsubnet=10.0.1.0/24
right=someip
rightsubnet=10.0.0.0/8
[...]
With NETKEY, since it enforces ipsec policy before routing, your ipsec
gateway on 10.0.1.1 will now send packets for 10.0.1.2 over the VPN!
In other words, you lose all connectivity with the LAN.
The work around is to add:
conn netkey-exclude
left=10.0.1.1
leftsubnet=10.0.1.0/24
right=0.0.0.0
rightsubnet=10.0.1.0/24
authby=never
type=passthrough
auto=route
Note that due to https://bugs.xelerance.com/issues/907, you will need
to use either openswan 2.4.x or openswan 2.6.23 or higher if you need
such a passthrough route.
KLIPS does a longest prefix match first, and does not run into this problem.
However, people tend to run netkey on the spokes, since otherwise they
will need to update/compile klips for every new kernel release on all the
spokes, which is an administrative burden.
Note that for multiple local LAN ranges, you will need multiple passthrough
routes.
If you have a lan that's local but the openswan server is not in it, but
needs to route to it, then you need a different hack, contributed by
Harald Scharf:
iptables -I PREROUTING -t mangle -j ROUTE -s mysubnet1 -d myremotesubnet \
-oif interface to subnet with router
|