Can't create a tunnel IPsec Site to Site between OpenWRT and Fortigate

bryangt · November 16, 2025, 6:41pm

Hello everyone,

First of all, I should mention that I've read the IPsec documentation for Strongswan; I understand most of it, but there were some things I didn't, obviously. I managed to set up the tunnel for IKEv1 and IKEv2, but in both scenarios I can't inject traffic from network B.

My goal is this: I want to advertise 0.0.0.0/0 (any network) from Router A to Router B through a VPN tunnel to route specific sites or destinations, for example, 1.1.1.1.

The diagram: Network A (OpenWRT) - Network B (Fortigate)

RouterA (OpenWRT)

Firmware: OpenWrt 22.03.7 r20341-591b7e93d3 / LuCI openwrt-22.03 branch git-24.067.02332-4c1ddfb
Kernel: 5.10.221

/etc/config/ipsec

config ipsec
	list 'interface' 'wan'
	option 'zone' 'vpn'
	option 'debug' '1'

config 'remote' 'tunel-to-RouterB'
    option 'enabled' '1'
    option 'local_ip' '192.168.1.5'
    option 'gateway' ‘b.b.b.b’
    option 'authentication_method' 'psk'
    option 'pre_shared_key' ‘private_key
    option 'rekeytime' '4h'
    option 'keyingtries' '0'
    option 'mobike' '0'
    list   'crypto_proposal' 'fase_1'
    list   'tunnel' 'enlace_a'

config 'crypto_proposal' 'fase_1'
    option 'encryption_algorithm' 'aes256gcm'
    option 'dh_group' 'modp2048'
    option prf_algorithm 'prfsha256'

config 'tunnel' 'enlace_a'
    list   'local_subnet' '0.0.0.0/0'
    list 'remote_subnet' '10.0.2.0/24'
    option 'if_id' '357'
    option 'rekeytime' '1h'
    option 'startaction' 'none'
    option 'closeaction' 'none'
    list   'crypto_proposal' 'fase_2'
 
config 'crypto_proposal' 'fase_2'
    option 'encryption_algorithm' 'aes256gcm'
    option 'dh_group' 'modp2048'

/etc/ipsec.secret

b.b.b.b : PSK “private_key”

swanctl –list-conns

swanctl --list-conns
curl SSL backend 'mbedTLS/2.28.8' not supported, https:// disabled
red_cm: IKEv2, no reauthentication, rekeying every 14400s
  local:  192.168.1.5
  remote: b.b.b.b
  local pre-shared key authentication:
  remote pre-shared key authentication:
  enlace_a: TUNNEL, rekeying every 3600s
    local:  0.0.0.0/0
    remote: 10.0.2.0/24

RouterB (Fortigate)

config vpn ipsec phase1-interface
    edit "tunel-to-RouterA”
        set interface "port1"
        set ike-version 2
        set keylife 3600
        set peertype any
        set net-device disable
        set proposal aes256gcm-prfsha256
        set localid “b.b.b.b”
        set dhgrp 14
        set remote-gw a.a.a.a
        set psksecret ENC private_key
    next
end

config vpn ipsec phase2-interface
    edit “tunel-to-RouterA”
        set phase1name "tunel-to-RouterA”
        set proposal aes256gcm
        set dhgrp 14
        set keylifeseconds 28800
        set src-subnet 10.0.2.0 255.255.255.0
    next
end

Logs:

Sun Nov 16 17:40:56 2025 daemon.info ipsec: 07[ENC] generating INFORMATIONAL response 2 [ ]
Sun Nov 16 17:40:56 2025 daemon.info ipsec: 07[NET] sending packet: from 192.168.1.5[4500] to b.b.b.b[4500] (57 bytes)
Sun Nov 16 17:40:57 2025 daemon.info ipsec: 10[NET] received packet: from b.b.b.b[500] to 192.168.1.5[500] (432 bytes)
Sun Nov 16 17:40:57 2025 daemon.info ipsec: 10[ENC] parsed IKE_SA_INIT request 0 [ SA KE No N(NATD_S_IP) N(NATD_D_IP) N(FRAG_SUP) ]
Sun Nov 16 17:40:57 2025 daemon.info ipsec: 10[IKE] b.b.b.b is initiating an IKE_SA
Sun Nov 16 17:40:57 2025 daemon.info ipsec: 10[CFG] selected proposal: IKE:AES_GCM_16_256/PRF_HMAC_SHA2_256/MODP_2048
Sun Nov 16 17:40:58 2025 daemon.info ipsec: 10[IKE] local host is behind NAT, sending keep alives
Sun Nov 16 17:40:58 2025 daemon.info ipsec: 10[IKE] remote host is behind NAT
Sun Nov 16 17:40:58 2025 daemon.info ipsec: 10[ENC] generating IKE_SA_INIT response 0 [ SA KE No N(NATD_S_IP) N(NATD_D_IP) N(FRAG_SUP) N(CHDLESS_SUP) N(MULT_AUTH) ]
Sun Nov 16 17:40:58 2025 daemon.info ipsec: 10[NET] sending packet: from 192.168.1.5[500] to b.b.b.b[500] (448 bytes)
Sun Nov 16 17:40:58 2025 daemon.info ipsec: 11[NET] received packet: from b.b.b.b[4500] to 192.168.1.5[4500] (227 bytes)
Sun Nov 16 17:40:58 2025 daemon.info ipsec: 11[ENC] parsed IKE_AUTH request 1 [ IDi N(INIT_CONTACT) AUTH N(MSG_ID_SYN_SUP) SA TSi TSr ]
Sun Nov 16 17:40:58 2025 daemon.info ipsec: 11[CFG] looking for peer configs matching 192.168.1.5[%any]...b.b.b.b[b.b.b.b]
Sun Nov 16 17:40:58 2025 daemon.info ipsec: 11[CFG] selected peer config 'red_cm'
Sun Nov 16 17:40:58 2025 daemon.info ipsec: 11[IKE] authentication of 'b.b.b.b' with pre-shared key successful
Sun Nov 16 17:40:58 2025 daemon.info ipsec: 11[CFG] no IDr configured, fall back on IP address
Sun Nov 16 17:40:58 2025 daemon.info ipsec: 11[IKE] authentication of '192.168.1.5' (myself) with pre-shared key
Sun Nov 16 17:40:58 2025 daemon.info ipsec: 11[IKE] IKE_SA red_cm[3] established between 192.168.1.5[192.168.1.5]...b.b.b.b[b.b.b.b]
Sun Nov 16 17:40:58 2025 daemon.info ipsec: 11[IKE] scheduling rekeying in 14260s
Sun Nov 16 17:40:58 2025 daemon.info ipsec: 11[IKE] maximum IKE_SA lifetime 15700s
Sun Nov 16 17:40:58 2025 daemon.info ipsec: 11[CFG] selected proposal: ESP:AES_GCM_16_256/NO_EXT_SEQ
Sun Nov 16 17:40:58 2025 daemon.info ipsec: 11[IKE] CHILD_SA enlace_a{2} established with SPIs c290e5c9_i 076ecae0_o and TS 0.0.0.0/0 === 10.0.2.0/24
Sun Nov 16 17:40:58 2025 daemon.info ipsec: 11[ENC] generating IKE_AUTH response 1 [ IDr AUTH SA TSi TSr ]
Sun Nov 16 17:40:58 2025 daemon.info ipsec: 11[NET] sending packet: from 192.168.1.5[4500] to b.b.b.b[4500] (193 bytes)

Ping from RouterA (OpenWRT)

ping 10.0.2.90
PING 10.0.2.90 (10.0.2.90): 56 data bytes
64 bytes from 10.0.2.90: seq=0 ttl=255 time=5.206 ms
64 bytes from 10.0.2.90: seq=1 ttl=255 time=5.260 ms
64 bytes from 10.0.2.90: seq=2 ttl=255 time=5.239 ms
64 bytes from 10.0.2.90: seq=3 ttl=255 time=5.124 ms
64 bytes from 10.0.2.90: seq=4 ttl=255 time=5.137 ms

If anyone has done this, I'd appreciate any guidance.

brada4 · November 16, 2025, 6:59pm

That is long EOL.

Does last ping indicate tunnel being up succesfuly?

Please connect to your OpenWrt device using ssh and copy the output of the following commands and post it here using the "Preformatted text </> " button (red circle; this works best in the 'Markdown' composer view in the blue oval):

Remember to redact passwords, VPN keys, MAC addresses and any public IP addresses you may have:

ubus call system board

bryangt · November 16, 2025, 8:27pm

@brada4

Yes, I tried with the latest version, but I remember reading that there were problems creating these tunnels. I could also try again with the latest stable version.
Yes, I only have connectivity from Router A to RouterB's LAN network.
ubus call system board

{
        "kernel": "5.10.221",
        "hostname": "OpenWrt",
        "system": "MediaTek MT7621 ver:1 eco:3",
        "model": "Xiaomi Mi Router 4A Gigabit Edition",
        "board_name": "xiaomi,mi-router-4a-gigabit",
        "rootfs_type": "squashfs",
        "release": {
                "distribution": "OpenWrt",
                "version": "22.03.7",
                "revision": "r20341-591b7e93d3",
                "target": "ramips/mt7621",
                "description": "OpenWrt 22.03.7 r20341-591b7e93d3"
        }
}

Thank you for your interest and time.

_bernd · November 16, 2025, 8:40pm

What does ip route say and IP xfrm ?

You may need to install ip-full.

brada4 · November 16, 2025, 9:06pm

v24 gets ipsec hardware accelerator supported in that device, 300Mbps typically)
here about ipsec policy xfrm ported to nftables (not as straightforward as iptables-translate-load)

github.com/openwrt/firewall4

Firewall is not working for IPSec NAT-T

opened 11:35AM - 02 Mar 25 UTC

kouhj

Tested two OpenWRT 24.10 routers to setup a site to site IPSec connection with S…trongswan when the WAN interfaces are over NATed network. After the firewall config were modified to accept the incoming ESP protocol and UDP 500, 4500 ports on the WAN interface (The default config of OpenWRT, which accepts redirecting ESP and UDP 500 to LAN, does not seem to work even to establish the connection), the two routers were able to establish the IPSec connection, and the following commands all reported normal results: `swanctl --list-sas` `ip xfrm state` `ip xfrm policy` `ip route show table 220` **BUT the normal site to site traffic just can get through when tested with ping.** If the firewall is stopped on the router that initiates the ping, it worked just fine to reach the other router. And unreachable again if the firewall is re-enabled. Followed these articles, https://docs.strongswan.org/docs/latest/howtos/forwarding.html https://docs.strongswan.org/docs/latest/howtos/trafficDumps.html and found that the LAN traffic can pass the `postrouting` chain of the `mangle` table with this command `iptables -t mangle -I POSTROUTING -m policy --pol ipsec --dir out -j NFLOG --nflog-group 5`. The key seems how to add a nftables rule in `POSTROUTING` chain of the `nat` table like the command `iptables -t nat -I POSTROUTING -m policy --pol ipsec --dir out -j ACCEPT` pointed out in the Strongswan doc mentioned above. Tried the following and no luck: `nft insert rule inet fw4 srcnat oif WAN ipsec out reqid 1 counter accept` `nft insert rule inet fw4 mangle_postrouting oif WAN ipsec out reqid 1 counter accept` The reqid 1 is confirmed with `swanctl --list-sas` Any ideas how to make IPSec NAT-T work with fw4? Thanks!

(edit - probably stable ipsec host-to-host / site-to-site could go to nftables.d example as it can not be properly expressed in fw rules, it is not a problem in roadrunners, so little complaints IRL)