22.03 Firewall not working (strongswan ipsec)


Strange and stubborn issue with Firewall when trying to connect 2 OWrt (22.03 and 18.06) routers ipsec tunnel.

All strongswan settings seems are OK, as I'm able to connect 2 routers if I set up tunnel using local network (certs are OK, CN are correct and I also use Alternative DNS etc etc).
However, If I'm trying to connect 2 public addresses (yes, I changed CN in the certs) - one side (22.03 router) doesn't receive communication from another one. There's NO NAT (22.03 is plugged in another router, but it's in bridge mode and works as a MediaConverter from fiber to ethernet, so 22.03 gets public IP).

  1. PORTS on both sides are OPEN:
    Both firewalls ACCEPT INPUT to the routers (no forwarding to LAN needed).
    Traffic rules also accept INPUT ipsec and ISAKMP
    I even turned firewalls OFF on both sides (WAN INPUT and OUTPUT was set to ACCEPT)

  2. Tested with nmap from another third public address:

500/udp open|filtered isakmp

4500/udp open|filtered nat-t-ike

500/udp open  isakmp

  1. I'm able to connect other ports (like https) from outside, so MediaConverter router should not be an issue.
52243/tcp open  unknown
  1. NO ERRORS in ipsec logs (except as described below)

BUT what I see:
22.03 sends packets to 18.06,
18.06 receives them and replies, then saying remote is unreachable (retransmits), then deletes half open connection
22.03 doesn't receive anything (neither as an initiator, nor as a responder)

I suppose it's a 22.03 netfilter's problem, as I was able to connect two 18.06 previously (with no MediaConverter in between).
Although, this looks OK on 22.03,

chain input_wan {
                meta nfproto ipv4 udp dport 68 counter packets 0 bytes 0 accept comment "!fw4: Allow-DHCP-Renew"
                icmp type echo-request counter packets 59 bytes 2172 accept comment "!fw4: Allow-Ping"
                meta nfproto ipv4 meta l4proto igmp counter packets 110 bytes 3520 accept comment "!fw4: Allow-IGMP"
                meta nfproto ipv6 udp dport 546 counter packets 0 bytes 0 accept comment "!fw4: Allow-DHCPv6"
                meta l4proto ipv6-icmp ip6 saddr fe80::/10 counter packets 0 bytes 0 accept comment "!fw4: Allow-MLD"
                icmpv6 type { destination-unreachable, time-exceeded, echo-request, echo-reply, nd-router-solicit, nd-router-advert } limit rate 1000/second counter packets 0 bytes 0 accept comment "!fw4: Allow-ICMPv6-Input"
                icmpv6 type . icmpv6 code { packet-too-big . no-route, parameter-problem . no-route, nd-neighbor-solicit . no-route, nd-neighbor-advert . no-route, parameter-problem . admin-prohibited } limit rate 1000/second counter packets 0 bytes 0 accept comment "!fw4: Allow-ICMPv6-Input"
                meta l4proto esp counter packets 0 bytes 0 accept comment "!fw4: Allow-IPSec-ESP"
                udp dport { 500, 4500 } counter packets 0 bytes 0 accept comment "!fw4: Allow-ISAKMP"
                jump reject_from_wan

please notice open|filtered for ports 500 and 4500 in nmap's reply.

Firewall fails?

First, you should upgrade the 18.06 router especially if security is an issue.

IPSec has two ways to control what goes through VPN and what doesn't, the old policy based and the newer xfrm based. I don't know if xfrm can be run on 18.06.

If you're tunneling the whole Internet out of one end, the routing table is important (the tricky part is that the encrypted packets have to go out to the raw Internet, they can't go into the tunnel). It is not so much of an issue with a site to site that only VPNs a subnet.

For this situation of a private point to point between two OpenWrt routers, I'd really recommend Wireguard. IPSec is quite tricky.

Like most UDP based services, nmap won't find the port open, since the kernel will just drop any stray or probing packets that aren't properly encrypted for an existing SA.

Thanks for response.

  1. Can't upgrade one device, no support anymore, 18.06 is the last one. (

  2. Regarding XFRM - I was able to setup 18.06 <-> 22.03 tunnel, when no routers were in between. So I think ipsec on each device handles all right way, despite the version.

  3. I'm tunneling subnets.

  4. WG is interesting solution, TNX (need to understand if it supports net-net connections)

I suppose the issue is either poor bridging in the intermediary fiber-optic router (Planet), or 22.03 firewall... Can't check "poor bridging" version as I can't find RJ-45 WAN ethernet to exclude unneeded Planet, everybody have SFP optic service providers here.....

  1. OK, intermediary router was a problem, even it was bridged and supposed to work as a MediaConverter. Without it, both routers set up the tunnel, SPI is assigned to each, routers can reach each other.

  2. XFRM is related to routing and this is another stage, related to establishing CHILD SA, which you can't achieve before first stage is completed.

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