IPsec routing (firewall4)

dchard · May 8, 2022, 9:54am

I managed to set up an IKEv1 IPsec tunnel (Strongswan) on OWRT master (with firewall4), but despite the left and right subnets are configured correctly, the packets towards the rightsubnet are still forwarded towrads the WAN interface instead of the VPN tunnel itself.

I tried to use this comment], but the

  option extra_src   '-m policy --dir in --pol ipsec --proto esp'
  option extra_dest  '-m policy --dir out --pol ipsec --proto esp'

options are not supported under firewall4.

I think the only thing I need is to set up routing/firewalling between the 192.168.2.0/24 (left subnet) and 10.5.5.0/24 (right subnet) and then it should be fine.

I have read all the suggested topics, no luck there. Interesting thing is, that when I use the exact same ipsec.conf on a VM behind the router (bridged to the LAN subnet), then the routing works, I can reach the remote end through the tunnel.

The tunnel itself is up as much as I can tell (server end also tells tunnel is up):

Connections:
VPN_NOC-VPN_NOC_c:  %any...144.178.x.x  IKEv1 Aggressive, dpddelay=10s
VPN_NOC-VPN_NOC_c:   local:  [xxxx.yyyyyy.zzzz] uses pre-shared key authentication
VPN_NOC-VPN_NOC_c:   remote: [144.178.x.x] uses pre-shared key authentication
VPN_NOC-VPN_NOC_c:   child:  192.168.2.0/24 === 10.5.5.0/24 TUNNEL, dpdaction=start
Security Associations (1 up, 0 connecting):
VPN_NOC-VPN_NOC_c[1]: ESTABLISHED 35 minutes ago, 84.236.x.x[xxxx.yyyyyy.zzzz]...144.178.x.x[144.178.x.x]
VPN_NOC-VPN_NOC_c[1]: IKEv1 SPIs: cc404d97959217f9_i* b89431274e1684cb_r, pre-shared key reauthentication in 2 hours
VPN_NOC-VPN_NOC_c[1]: IKE proposal: AES_CBC_192/HMAC_SHA2_256_128/PRF_HMAC_SHA2_256/MODP_3072
VPN_NOC-VPN_NOC_c{1}:  REKEYED, TUNNEL, reqid 1, expires in 24 minutes
VPN_NOC-VPN_NOC_c{1}:   192.168.2.0/24 === 10.5.5.0/24
VPN_NOC-VPN_NOC_c{2}:  INSTALLED, TUNNEL, reqid 1, ESP SPIs: c2e80c79_i f7792e8d_o
VPN_NOC-VPN_NOC_c{2}:  AES_CBC_192/HMAC_SHA2_256_128/MODP_3072, 0 bytes_i, 0 bytes_o, rekeying in 8 minutes
VPN_NOC-VPN_NOC_c{2}:   192.168.2.0/24 === 10.5.5.0/24

Any and all help is appreciated.

MOD: I looked at VPN Policy-Based Routing, but as much as it seems, this is not usable for IPsec as there is no "VPN" interface available...

dchard · May 8, 2022, 1:17pm

Hm... As IPsec involves policy based routing, I though I check that and here it is:

root@XAX6:~# ip rule show
0:      from all lookup local
220:    from all lookup 220
32766:  from all lookup main
32767:  from all lookup default
root@XAX6:~#
root@XAX6:~# ip route show table 220
10.5.5.0/24 via 10.0.0.1 dev pppoe-digi proto static src 192.168.2.254

Table 220 is the one for IPsec, and that single rule is quite clearly incorrect.

Just for comparison, the same rule on the VM (where the same IPsec conf works flawlessly) looks like this:

10.5.5.0/24 via 192.168.2.254 dev ens33 proto static src 192.168.2.60

This is the ipsec.conf on the router:

conn ipsec_tunnel
  left=%any
  right=144.178.x.x
  leftfirewall=no
  rightfirewall=no
  ikelifetime=3h
  lifetime=1h
  margintime=9m
  keyingtries=3
  dpdaction=restart
  dpddelay=20s
  dpdtimeout=90s
  leftauth=psk
  rightauth=psk
  auto=start
  leftsubnet=192.168.2.0/24
  leftid=xxxxx.yyyyyy.zzzzzz
  aggressive=yes
  forceencaps=no
  type=tunnel
  keyexchange=ikev1
  esp=aes192-sha256-modp3072
  ike=aes192-sha256-modp3072
  rightsubnet=10.5.5.0/24
  fragmentation = no

What do I have to change to fix the polcy based route ipsec creates on its own?

pavelgl · May 12, 2022, 9:33am

Try inserting the following nftables rule

nft insert rule inet fw4 srcnat ip daddr 10.5.5.0/24 counter accept

dchard · May 12, 2022, 10:10pm

Thanks, that resolved it completely. Will mark your answer as a solution, but if you can shed some lite on some details that would be lovely:

Does this means I can disable "installpolicy" and I need to load this rule manually?
Does my config has any errors, or this extra rule is needed because of fw4?

I read all the available docus and topics here on IPsec, but this seemingly vital piece of information is nowhere to be found.

pavelgl · May 13, 2022, 8:42am

I would recommend you to read this great article. It is long, but definitely worth the time.

https://thermalcircle.de/doku.php?id=blog:linux:nftables_ipsec_packet_flow

By default fw4 (nftables) masquerades all egress traffic leaving the wan interface. You must exclude the traffic destined to 10.5.5.0/24 from this process to get it through the tunnel.

Yes, you can disable the VPN Policy-Based Routing. Regarding loading the rule, try this:

cat << "EOF" > /etc/nftables.d/20-ipsec.nft
chain ipsec_chain {
     type nat hook postrouting priority -1;
     ip daddr 10.5.5.0/24 counter accept
}
EOF
fw4 restart

If it doesn't work as expected, remove /etc/nftables.d/20-ipsec.nft and place the rule in /etc/rc.local, but set some delay.

sleep 30
nft insert rule inet fw4 srcnat ip daddr 10.5.5.0/24 counter accept

exit 0

BTW, if you need access from 10.5.5.0/24 to 192.168.2.0/24, you will need another rule

nft insert rule inet fw4 forward ip saddr 10.5.5.0/24 counter accept

jow · May 13, 2022, 11:22am

There's an option for that. Within the wan zone, set
list masq_dest !10.5.5.0/24

That will exempt the 10.5.5.0/24 subnet from masquerading. This way no manual rules are required.

cwbsw · May 14, 2022, 1:11am

My opinion, if you can not solve it, configure route-based vpn instead, just:

opkg install luci-proto-xfrm xfrm

config interface 'tunnel1'
	option proto 'xfrm'
	option ifid '1'
	option mtu '1380'
	option tunlink 'lan'

config interface 'tunnel1-alias'
    option device '@tunnel1'
    option proto 'static'
    option ipaddr '****'
    option netmask '****'

connections {
    tunnel1 {
        ****
        if_id_in=1
        if_id_out=1
        ****
        children {
            tunnel1-child1 {
                ****
                local_ts=0.0.0.0/0
                remote_ts=0.0.0.0/0
                ****
            }
        }
    }
}

and then configure xfrm interface like a normal interface.

dchard · May 14, 2022, 8:37am

@jow

If I understand it correctly, if I set the "Restrict Masquerading to given source subnets" to my LAN subnet under the WAN zone, will that behave like what you explained? So my issue in a nutshell is that NAT happens before the policy route can happen?

MOD: Just realized how stupid my question is, as if I limit masquerading to my LAN subnet, I will exactly be at where I am now without it

@pavelgl mapping the traffic to an interface sounds like an interesting option. Would certainly make my routing logic much easier to follow. So I might try it.

dchard · May 14, 2022, 12:53pm

@jow

One more question: after I switched to fw4, is it normal if I still have some iptable modules loaded?

root@XAX6:~# lsmod | grep "iptable"
ip_tables              24576  3 iptable_nat,iptable_mangle,iptable_filter
iptable_filter         16384  1
iptable_mangle         16384  0
iptable_nat            16384  0
nf_nat                 32768  8 iptable_nat,xt_nat,xt_REDIRECT,xt_MASQUERADE,nft_redir,nft_nat,nft_masq,nft_chain_nat
x_tables               28672 33 iptable_nat,xt_state,xt_nat,xt_conntrack,xt_REDIRECT,xt_MASQUERADE,xt_FLOWOFFLOAD,ipt_REJECT,xt_time,xt_tcpudp,xt_quota,xt_policy,xt_pkttype,xt_physdev,xt_owner,xt_multiport,xt_mark,xt_mac,xt_limit,xt_esp,xt_comment,xt_cgroup,xt_addrtype,xt_TCPMSS,xt_LOG,iptable_mangle,iptable_filter,ipt_ah,ip_tables,ip6table_mangle,ip6table_filter,ip6_tables,ip6t_REJECT

Or maybe this is some leftover stuff after the migration which should not be there?

dchard · May 18, 2022, 8:26am

Okke, just to summarize it:

Both the solution of pavelgl and jow are functionally working, but jow's solution is more elegant so I am choosing that one. Non the less the detailed explanation of pavelgl is highly appreciated.

Just to recap, the problem was the by default fw4 (nftables) masquerades all egress traffic leaving the wan interface, including the VPN traffic. To prevent this, the following line needs to be added to the WAN zone section of /etc/config/firewall config file:

config zone
        option name 'wan'
        option input 'REJECT'
        option output 'ACCEPT'
        option forward 'REJECT'
        option masq '1'
        option mtu_fix '1'
        list network 'digi'
        list masq_dest '!10.5.5.0/24'

Then reload and restart the firewall:

/etc/init.d/firewall reload
/etc/init.d/firewall restart

If someone is more comfortable with the webgui, just edit the WAN zone, go to Additional settings:

Of course if you want more subnets to go through the VPN tunnel, you can add multiple subnets.

llogar · May 18, 2022, 11:29am

@jow Perhaps it wouldn't be a bad idea to add nft_xfrm module support to netfilter.mk. Something like

define KernelPackage/nft-xfrm
  SUBMENU:=$(NF_MENU)
  TITLE:=Netfilter nft_xfrm support
  DEPENDS:=+kmod-nft-core
  KCONFIG:= \
	CONFIG_NFT_XFRM
  FILES:= \
	$(LINUX_DIR)/net/netfilter/nft_xfrm.ko
  AUTOLOAD:=$(call AutoProbe,nft_xfrm)
endef

$(eval $(call KernelPackage,nft-xfrm))

At least on strongSwan (using updown plugin) you could then use
nft insert rule ... meta ipsec exists ipsec in|out reqid nnn accept
to dinamically add/remove fw4 rules?

system · May 28, 2022, 11:29am

This topic was automatically closed 10 days after the last reply. New replies are no longer allowed.