- \n
- All internet-bound traffic from the container is routed via remote VPN.<\/li>\n\n\n\n
- Container must not be able to communicate with any other networks the host might be directly connected to.<\/li>\n\n\n\n
- The container itself has no knowledge about the VPN.<\/li>\n\n\n\n
- If the VPN does not work, the container can’t communicate with internet services.<\/li>\n<\/ul>\n<\/li>\n\n\n\n
- Debian 13 host<\/strong>:\n
- \n
- strongSwan handles IPSec IKEv2 connections with the remote VPN service.<\/li>\n\n\n\n
- Network traffic originating from the host system is not routed via the VPN service.<\/li>\n<\/ul>\n<\/li>\n\n\n\n
- Remote IPSec IKEv2 VPN service<\/strong>:\n
- \n
- Not under our control.<\/li>\n\n\n\n
- Assigns a single virtual IPv4 address.<\/li>\n<\/ul>\n<\/li>\n<\/ul>\n\n\n\n
![\"\"](\"https:\/\/macadmin.cz\/wp-content\/uploads\/basenetwork.png\")
<\/a>The initial network diagram<\/figcaption><\/figure>\n\n\n\n IPv4 ranges (RFC1918) used in the example<\/p>\n\n\n\n
- \n
192.168.99.0\/24<\/code> – network the host is connected to<\/li>\n\n\n\n192.168.222.0\/24<\/code> – host-only network for the container(s)<\/li>\n\n\n\n10.9.8.7\/32<\/code> – VPN virtual IP<\/li>\n<\/ul>\n\n\n\nLet’s take a brief look at a base VPN configuration. It is very easy to configure a policy-based IKEv2 VPN for the host. Example
swanctl.conf<\/code>:<\/p>\n\n\n\npolicy-based-vpn {\n version = 2\n\n local_addrs = 192.168.99.98\n remote_addrs = remote-vpn-gateway.macadmin.cz\n vips = 0.0.0.0\n\n local {\n auth = pubkey\n id = vpn-client.macadmin.cz\n }\n\n remote {\n auth = pubkey\n id = remote-vpn-gateway.macadmin.cz\n }\n\n children {\n netvpn {\n remote_ts = 0.0.0.0\/0\n start_action = trap\n }\n }\n}\n<\/pre><\/div>\n\n\nThe challenge is how to make it work for the traffic originating from the container
and exclude all traffic originating from the host system. The host only network192.168.222.0\/24<\/code>, the container is connected to, will have to be NATed behind a single IPv4 address to match the 1:1 expectation of the VPN service. First I tried to come up with a solution using policy-based VPN configuration, but after some thinking I figured a route-based VPN<\/a> might be a better fit for this situation.<\/p>\n\n\n\nThe plan:<\/p>\n\n\n\n
- \n
- Create XFRM interface
ipsec0<\/code> and assign IPSec policy with match-all-traffic selector0.0.0.0\/0<\/code>.<\/li>\n\n\n\n- Create source routing table which will apply to all traffic originating from the host-only network and use it to route the traffic to
ipsec0<\/code> interface.<\/li>\n\n\n\n- Use
nftables<\/code> to configure Source NAT onipsec0<\/code>.<\/li>\n\n\n\n- Make sure virtual IPv4 address assigned by the VPN server gets assigned to
ipsec0<\/code> and not any another interface.<\/li>\n<\/ol>\n\n\n\n\n\n\n\nPrepwork<\/h2>\n\n\n\n
Install packages:<\/p>\n\n\n\n
- \n
bridge-utils<\/code><\/li>\n\n\n\nnftables<\/code><\/li>\n\n\n\ncharon-systemd<\/code><\/li>\n\n\n\nstrongswan-swanctl<\/code><\/li>\n\n\n\nlibstrongswan-extra-plugins<\/code><\/li>\n\n\n\nlibcharon-extra-plugins<\/code><\/li>\n<\/ul>\n\n\n\nEnable routing in kernel:<\/p>\n\n\n\n
- \n
- Run
sysctl -w net.ipv4.ip_forward=1<\/code> <\/li>\n\n\n\n- Check
\/etc\/sysctl.conf<\/code> to see if the setting is present.<\/li>\n<\/ol>\n\n\n\nCreate
vpnrouting<\/code> source routing table:<\/p>\n\n\n\n- \n
mkdir -p \/etc\/iproute2\/rt_tables.d<\/code><\/li>\n\n\n\necho 100 vpnrouting >> \"\/etc\/iproute2\/rt_tables.d\/vpnrouting.conf<\/code>“<\/li>\n<\/ol>\n\n\n\nConfiguring interfaces<\/h2>\n\n\n\n
ip link add ipsec0 type xfrm if_id 42<\/code> commands create aipsec0<\/code> xfrm interface which is listed asipsec0@NONE<\/code>. However, this change is not persistent. The interface would have to be created via every boot via a hook script or a custom service.<\/p>\n\n\n\nI wanted a static configuration. Turns out this is not easily doable with
ifupdown<\/code> configuration in\/etc\/network\/interfaces<\/code>. There is a discussion post<\/a> in the strongSwan GitHub repo which shows the static configuration can be done withsystem-network<\/code>.<\/p>\n\n\n\nDebian 13 does not use
systemd-network<\/code> by default. Instead, NetworkManager is used for GUI installs andifupdown<\/code> for headless setups. I followed the Debian SystemdNetworkd article<\/a> and:<\/p>\n\n\n\n- \n
- Disabled all
ifupdown<\/code> interface configuration files.<\/li>\n\n\n\n- Created configuration files in the
\/etc\/systemd\/network<\/code> directory (see below).<\/li>\n\n\n\n- Enabled (
systemctl enable systemd-networkd<\/code>) and started (systemctl start systemd-networkd<\/code>) thesystemd-networkd<\/code> <\/strong>service.<\/li>\n<\/ol>\n\n\n\nbr-lxc0.netdev<\/strong><\/code><\/p>\n\n\n\n[NetDev]\nName=br-lxc0\nKind=bridge\n\n[Bridge]\nSTP=false\nForwardDelaySec=0\n<\/pre><\/div>\n\n\n
\n\n\n\nbr-lxc0.network<\/strong><\/code><\/p>\n\n\n\n[Match]\nName=br-lxc0\n\n[Network]\nAddress=192.168.222.1\/24\nConfigureWithoutCarrier=yes\n\n[Link]\nActivationPolicy=always-up\n\n[Route]\nDestination=192.168.222.0\/24\nTable=100\n<\/pre><\/div>\n\n\n
\n\n\n\nloopback.network<\/code><\/strong><\/p>\n\n\n\n[Match]\nName=lo\n\n[Network]\nXfrm=ipsec0\n<\/pre><\/div>\n\n\n
\n\n\n\nipsec0.netdev<\/code><\/strong><\/p>\n\n\n\n[NetDev]\nName=ipsec0\nKind=xfrm\n\n[Xfrm]\nInterfaceId=17\n<\/pre><\/div>\n\n\n
\n\n\n\nipsec0.network<\/code><\/strong><\/p>\n\n\n\n[Match]\nName=ipsec0\n\n[Link]\nActivationPolicy=always-up\n\n[Route]\nGateway=0.0.0.0\nTable=100\n\n[RoutingPolicyRule]\nFrom=192.168.222.0\/24\nTable=100\n<\/pre><\/div>\n\n\n
There is one more thing. Systemd will happily override
net.ipv4.ip_forward<\/code> during system boot, thus disabling the routing. To prevent this from happening, make sure to setIPv4Forwarding=yes<\/code> in\/etc\/systemd\/networkd.conf<\/code>.<\/p>\n\n\n\nWith the
systemd-networkd<\/code> running, configuration can be inspected to checkipsec0<\/code> interface is present and source routing configured. <\/p>\n\n\n\nip a<\/strong><\/code><\/p>\n\n\n\n1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000\n link\/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00\n inet 127.0.0.1\/8 scope host lo\n\n2: eno0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP group default qlen 1000\n link\/ether fe:dc:ba:09:87:65 brd ff:ff:ff:ff:ff:ff\n inet 192.168.99.98\/24 brd 192.168.99.255 scope global dynamic noprefixroute eno0\n\n3: br-lxc0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default qlen 1000\n link\/ether fe:dc:ba:09:87:64 brd ff:ff:ff:ff:ff:ff\n inet 192.168.222.1\/24 brd 192.168.222.255 scope global br-private0\n\n4: ipsec0@lo: <NOARP,UP,LOWER_UP> mtu 1500 qdisc noqueue state UNKNOWN group default qlen 1000\n link\/none \n<\/pre><\/div>\n\n\n
\n\n\n\nip rule<\/strong><\/code><\/p>\n\n\n\n0: from all lookup local\n220: from all lookup 220\n32765: from 192.168.222.0\/24 lookup vpnrouting proto static\n32766: from all lookup main\n32767: from all lookup default\n<\/pre><\/div>\n\n\n
\n\n\n\nip route list table vpnrouting<\/strong><\/code><\/p>\n\n\n\ndefault dev ipsec0 proto static scope link\n192.168.222.0\/24 dev br-lxc0 proto static scope link\n<\/pre><\/div>\n\n\n
nftables configuration<\/h2>\n\n\n\n
\/etc\/nftables.conf<\/code><\/strong><\/p>\n\n\n\ntable inet filter {\n chain forward {\n type filter hook forward priority filter; policy drop;\n iifname "br-lxc0" oifname "ipsec0" accept\n iifname "ipsec0" oifname "br-lxc0" ct state established,related accept\n }\n\n chain nat {\n type nat hook postrouting priority srcnat; policy accept;\n oifname "ipsec0" masquerade\n }\n}\n<\/pre><\/div>\n\n\nRouting rules implicitly prevent the container traffic from going to undesirable places.
Explicit firewall configuration in the forward chain ensures this.
Source NAT configured with masquerade translates the source IPv4 of all packets leaving theipsec0<\/code> interface before they are encapsulated. The new address is the virtual IPv4 address assigned by the VPN service and attached to the interface by strongSwan.<\/p>\n\n\n\nstrongSwan configuration<\/h2>\n\n\n\n
\/etc\/swanctl\/conf.d\/connections.conf<\/em><\/strong><\/p>\n\n\n
\nroute-based-vpn {\n version = 2\n\n local_addrs = 192.168.99.98\n remote_addrs = remote-vpn-gateway.macadmin.cz\n vips = 0.0.0.0\n\n local {\n auth = pubkey\n id = vpn-client.macadmin.cz\n }\n\n remote {\n auth = pubkey\n id = remote-vpn-gateway.macadmin.cz\n }\n\n children {\n netvpn {\n local_ts = 0.0.0.0\/0\n remote_ts = 0.0.0.0\/0\n if_id_in = 17\n if_id_out = 17\n start_action = trap\n }\n }\n}\n<\/pre><\/div>\n\n\nConsider enabling dead pear detection (DPD) and appropriate action when that happens. Example values:<\/p>\n\n\n
\ndpd_delay = 300s\nchildren.netvpn.dpd_action = clear\n<\/pre><\/div>\n\n\n
Tell strongSwan to assign the virtual IP address onto
ipsec0<\/code> interface by usinginstall_virtual_ip_on<\/code> key inn\/etc\/strongswan.conf<\/em><\/code>:<\/p>\n\n\n\ncharon {\n load_modular = yes\n plugins {\n include strongswan.d\/charon\/*.conf\n }\n install_virtual_ip_on = ipsec0\n}\n\ninclude strongswan.d\/*.conf\n<\/pre><\/div>\n\n\nI learned about this by reading a discussion<\/a> in strongSwan GitHub repo. This GitHub issue<\/a> is also somewhat relevant.<\/p>\n\n\n\n
Conclusion<\/h2>\n\n\n\n
With all the pieces in place a reboot might be required. Alternatively make sure the services are restarted\/reloaded in order:<\/p>\n\n\n\n
- \n
systemd-networkd<\/code><\/li>\n\n\n\nnftables<\/code><\/li>\n\n\n\nstrongswan<\/code><\/li>\n<\/ol>\n\n\n\n![\"\"](\"https:\/\/macadmin.cz\/wp-content\/uploads\/net2.drawio.png\")
<\/a>Final configuration diagram<\/figcaption><\/figure>\n\n\n\n Additional resources<\/h2>\n\n\n\n
strongSwan<\/h3>\n\n\n\n
- \n
- Introduction to strongSwan<\/a><\/li>\n\n\n\n
- Security Recommendations<\/a><\/li>\n\n\n\n
- Route-based VPN<\/a><\/li>\n\n\n\n
- strongswan.conf<\/a><\/li>\n\n\n\n
- swanctl.conf<\/a><\/li>\n<\/ul>\n\n\n\n
Debian<\/h3>\n\n\n\n
- \n
- SystemdNetworkd<\/a><\/li>\n\n\n\n
- SYSTEMD.NETWORK(5)<\/a><\/li>\n<\/ul>\n\n\n\n
XFRM<\/h3>\n\n\n\n
- \n
- Cilium XFRM Reference Guide<\/a><\/li>\n\n\n\n
- Linux XFRM Reference Guide for IPsec<\/a><\/li>\n\n\n\n
- Nftables – Netfilter and VPN\/IPsec packet flow
<\/a>
<\/a>
<\/li>\n<\/ul>\n\n\n\n<\/p>\n","protected":false},"excerpt":{"rendered":"
Recently, I implemented an interesting scenario involving Linux networking and VPN. These were the requirements: IPv4 ranges (RFC1918) used in the example Let’s take a brief look at a base VPN configuration. It is very easy to configure a policy-based IKEv2 VPN for the host. Example swanctl.conf: The challenge is how to make it work … <\/p>\n
- Linux XFRM Reference Guide for IPsec<\/a><\/li>\n\n\n\n
- SYSTEMD.NETWORK(5)<\/a><\/li>\n<\/ul>\n\n\n\n
- Security Recommendations<\/a><\/li>\n\n\n\n
- Created configuration files in the
- Check
- Create source routing table which will apply to all traffic originating from the host-only network and use it to route the traffic to