IPsec routing (firewall4)

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 (left subnet) and (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):

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: === 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}: ===
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}: ===

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

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:~# ip route show table 220 via dev pppoe-digi proto static src

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: via dev ens33 proto static src

This is the ipsec.conf on the router:

conn ipsec_tunnel
  fragmentation = no

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

Try inserting the following nftables rule

nft insert rule inet fw4 srcnat ip daddr counter accept

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:

  1. Does this means I can disable "installpolicy" and I need to load this rule manually?

  2. 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.

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


By default fw4 (nftables) masquerades all egress traffic leaving the wan interface. You must exclude the traffic destined to 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 counter accept
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 counter accept

exit 0

BTW, if you need access from to, you will need another rule

nft insert rule inet fw4 forward ip saddr counter accept

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

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


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 {
        children {
            tunnel1-child1 {

and then configure xfrm interface like a normal interface.

1 Like


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 :slight_smile:

@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.


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?

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 '!'

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.

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

define KernelPackage/nft-xfrm
  TITLE:=Netfilter nft_xfrm support
  FILES:= \
  AUTOLOAD:=$(call AutoProbe,nft_xfrm)

$(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?

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