[strongSwan] StrongSwan w/ multiple local subnets.

[Tobias Brunner]

Hi Tom,

> This is a DD-WRT router. Uses a pre-built kernel I might not have too 
> much option in customizing it.  But I tried removing it

kernel-libipsec is a userland IPsec implementation (read the wiki page),
it has nothing to do with the kernel (except that it has to be able to
create TUN devices).

However, to use the kernel's IPsec stack, it is missing an important module:

> Jun 22 08:12:15 DD-WRT daemon.info charon: 00[KNL] unable to create 
> netlink socket: Protocol not supported (93)
> Jun 22 08:12:15 DD-WRT daemon.info charon: 00[NET] could not open 
> socket: Address family not supported by protocol
> Jun 22 08:12:15 DD-WRT daemon.info charon: 00[NET] could not open IPv6 
> socket, IPv6 disabled
> Jun 22 08:12:15 DD-WRT daemon.info charon: 00[NET] installing IKE bypass 
> policy failed
> Jun 22 08:12:15 DD-WRT daemon.info charon: 00[NET] installing IKE bypass 
> policy failed
> Jun 22 08:12:15 DD-WRT daemon.info charon: 00[NET] enabling UDP 
> decapsulation for IPv4 on port 4500 failed
> Jun 22 08:12:15 DD-WRT daemon.info charon: 00[LIB] feature 
> CUSTOM:libcharon in critical plugin 'charon' has unmet dependency: 
> CUSTOM:kernel-ipsec

> Interestingly, what I do have is:

What you are definitely missing is xfrm_user, which is required for the
daemon to communicate with the kernel.  Without that module all the
others are pretty much useless, so no idea why your kernel is configured
like that.

> I no longer have to run:
> 
> ip route add 10.10.0.0/24 dev ipsec0
> 
> for packets to show up on ipsec0:

As I mentioned, strongSwan installs a route automatically if there is a
local IP in the local traffic selector.  You can see those in table 220.

> root at DD-WRT:~# tcpdump -i ipsec0 -s 0 -n
> tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
> listening on ipsec0, link-type RAW (Raw IP), snapshot length 262144 bytes
> 08:44:28.318516 IP 100.100.100.100  > 10.10.0.4: ICMP echo request, id 
> 36426, seq 0, length 64
> 08:44:29.325741 IP 100.100.100.100  > 10.10.0.4: ICMP echo request, id 
> 36426, seq 1, length 64
> 
> but not anymore.

No you won't as these packets don't match the negotiated traffic
selectors.  The local TS is 192.168.0.0/24, which obviously doesn't
match 100.100.100.100 so libipsec will drop the packet.   If there was a
route in table 220 it should list a source IP in the local traffic
selector, so it's interesting that a different source IP was selected -
or was that IP forced somehow?

> Still 
> looking at Brian's recommendations however:
> 
> root at DD-WRT:~# ip link add xfrm0 type xfrm dev ipsec0 if_id 42
> ip: RTNETLINK answers: Not supported
> root at DD-WRT:~# ip link add vti0 type vti dev ipsec0 if_id 42
> ip: RTNETLINK answers: Not supported
> root at DD-WRT:~#
> 
> Trying GRE but:
> 
> root at DD-WRT:~# ip tunnel add ipsec01 local 100.100.100.100 remote 
> 123.123.123.123 mode gre
> ip: ioctl 0x89f1 failed: No such device
> root at DD-WRT:~#

None of these will work without kernel IPsec support (and XFRM
interfaces are only available in 4.19+ kernels anyway).  But they should
also not be necessary for simple site-to-site tunnels.

Regards,
Tobias