Gecko [ 122.154.134.11 ]

Name	Size	Permission
hub-spoke.conf	1.47 KB	-rw-r--r--
ipv6.conf	1013 B	-rw-r--r--
l2tp-cert.conf	1.69 KB	-rw-r--r--
l2tp-psk.conf	1.78 KB	-rw-r--r--
linux-linux.conf	1.13 KB	-rw-r--r--
mast-l2tp-psk.conf	1.54 KB	-rw-r--r--
oe-authnull.conf	1.44 KB	-rw-r--r--
oe-exclude-dns.conf	235 B	-rw-r--r--
oe-upgrade-authnull.conf	1.52 KB	-rw-r--r--
sysctl.conf	2.18 KB	-rw-r--r--
xauth.conf	622 B	-rw-r--r--

Code Editor : hub-spoke.conf

# 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

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 is local but the libreswan 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/cidr> \
    -d <myremotesubnet/cidr> -oif <interface to subnet with router>

${this.title}

Code Editor : hub-spoke.conf