Strongswan IPSec Tunnel matching stadard rotes


I've been trying to set up stable ipsec tunnels using strongswan to connect to our network firewall (paloalto).

The firewall side uses a wide range of private IPs:, and also That makes me create three different tunnels so that clients behind openwrt can access everything.

I'm having real problems since I added the network to strongswan which is sort of a "legacy" network. It works ok for a while (meaning I can access this network from the Openwrt but very often this tunnel will go down and cause the other two tunnels to act strange.

Looking at the route output I get:

root@openwrt:/etc# route
Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
default         UG    0      0        0 eth2      *        U     0      0        0 br-lan     *        U     0      0        0 eth2     *      UH    0      0        0 eth2

I think the problem is happening mostly because the ISP side use the network as well which matches one of my tunnels.

How do I address such an issue? I'm planning to implement that on hundreds of devices with many different ISP configurations that I have no control.

config setup
        # strictcrlpolicy=yes
        # uniqueids = no

conn %default

conn paloalto
        rightid="DC=br, DC=com, DC=xyz, CN=CA-xyz"

conn xyz-lan

conn xyz-dmz

conn xyz-leg

Your ISP is using network which is not interfering with
Another thing is, that there is not needed to create three tunnels.
I have strongswan witch such configuration:


I had only one problem with strongswan on openwrt. Default openwrt configuration is doing NAT on any kind of network traffic. I disabled NATing for traffic beetween IPsec networks.

Here's another way to skip NAT for the VPN traffic. As an additional benefit, it allows you to define firewall rules specific to the VPN tunnel.
If you want to use a single set of rules for all VPN subnets, option subnet also accepts a list:

  option subnet  ''

For your IPsec config, I recommend to:

  • avoid IKEv1 aggressive mode
  • use IKEv2 if possible
  • use at least DH group 14 (modp2048) or elliptic curve DH
  • instead of auto=start and closeaction=restart, use auto=route

I'm not sure if auto=add is needed at all for a section which is only referenced with also=.

You are right about the network I was sure that it was using /8 don't know why. Strongswan only supports that syntax with IKEv2 for left/righ subnet. I had to restrict masquerading as well but I'm using "firewall.user" because Chaos Calmer has a bug and does not allow multiple subnetworks configured via UCI for that.

That's the way I'm doing:

iptables -t nat -A postrouting_wan_rule -d -j ACCEPT
iptables -t nat -A postrouting_wan_rule -d -j ACCEPT
iptables -t nat -A postrouting_wan_rule -d -j ACCEPT

That syntax is not supported for IKEv1 by strongswan. Why shouldn't I use agressive mode and IKEv2? And how is it related to the problem? I tried route without good results though.

Most importantly you really shouldn't be using CC for security reasons anymore.

Do you mean this one?

  option subnet  ''

It is meant to be used in a vpn firewall zone, as in the posting I linked to. It should work in combination with any strongswan config as long as the subnets match:

  • multiple conn sections (IKEv1 or IKEv2), one conn per subnet
  • single conn section with multiple subnets (IKEv2 only).

However, it may not work yet on Chaos Calmer.

The other configuration posted by @jtaczanowski is simpler, but does not have a separate vpn zone. You can choose whatever suits you best.

I second the advice to upgrade OpenWrt for security reasons. A recent OpenWrt release also comes with a newer strongswan which may improve stability and interoperability.

Sorry, my warning about IKEv1 aggressive mode does not apply in your case.
IKEv1 aggressive mode transmits a hash that can be used for brute-force cracking of a pre-shared key.
Since you are using certificates, you should be safe from this attack. The identity is still transmitted in the clear, however.
IKEv1 main mode is better in this regard. But since it transmits the identity later in the protocol, it can cause problems with credential selection on the responder.
IKEv2 does not distinguish between main/aggressive mode and does not have these issues.

I recommend to use IKEv2 if supported by the peer, it has many improvements over IKEv1. Further random examples:

  • better handling of dynamic IP addresses (MOBIKE)
  • fewer round-trips

Not related to the problem, just general advice.

With auto=route, the tunnel is established on-demand when traffic matches the policy.
You have to live with a small delay/packet drops when the tunnel is first established, but in my experience it's the most reliable configuration. Of course you should validate this with your devices. I use strongswan on both peers.

What were your results? Did IKE negotiation not happen at all?
Maybe auto=route will start working after you solved the NAT problem.