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
|
# 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 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>
|
