IKEV2 on OpenWrt as client

Hello OpenWrt community,

I have been using an IPSec IKEV2 configuration to connect to my VPN provider with my Linux machine.
Today I wanted to migrate the configuration from my PC to my router so that all devices connected to the LAN are automatically connected to the VPN server. So I simply copied the configuration from my Ubuntu to my OpenWrt router and it worked very well.

The only problem is that if I specify the rightsubnet parameter to 0.0.0.0/0 everything connected to the router is disconnected... But when I am in UART I can see that the router is well connected to the IPSecGW server as my ip has changed. But if I remove de parameter rightsubnet from the config file I'm also connected but my IP remains the same.

Here is my /etc/ipsec.conf content:

config setup
    strictcrlpolicy=no
    uniqueids = yes
    charondebug = "all"

conn %default
        ikelifetime=1h
        keylife=20h
        rekeymargin=3m
        keyingtries=1
        keyexchange=ikev2
        rekey=no

conn vpn
        dpdaction=clear
        dpddelay=300s
        eap_identity="My_Personal_ID"
        leftauth=eap-mschapv2
        left=%defaultroute
        leftsourceip=%config
        right=vpn_provider.com
        rightauth=pubkey
        rightsubnet=0.0.0.0/0
        rightid=%*.vpn_provider.com
        rightca=/etc/ipsec.d/cacerts/AddTrustExternalCARoot.pem
        type=tunnel
        auto=add
        ike=aes256-sha1-modp1024,aes128-sha1-modp1024,3des-sha1-modp1024!
        esp=aes256-sha256,aes256-sha1,3des-sha1!

Here is the output for the command "ipsec up vpn"

root@OpenWrt:/# ipsec start
no files found matching '/etc/strongswan.d/*.conf'
Starting strongSwan 5.8.4 IPsec [starter]...
root@OpenWrt:/# ipsec up vpn
no files found matching '/etc/strongswan.d/*.conf'
initiating IKE_SA vpn[1] to 104.217.249.147
generating IKE_SA_INIT request 0 [ SA KE No N(FRAG_SUP) N(HASH_ALG) N(REDIR_SUP) ]
sending packet: from 192.168.64.166[55213] to 104.217.249.147[500] (362 bytes)
received packet: from 104.217.249.147[500] to 192.168.64.166[55213] (280 bytes)
parsed IKE_SA_INIT response 0 [ SA KE No N(FRAG_SUP) N(HASH_ALG) N(MULT_AUTH) ]
selected proposal: IKE:AES_CBC_256/HMAC_SHA1_96/PRF_HMAC_SHA1/MODP_1024
sending cert request for "C=US, ST=New Jersey, L=Jersey City, O=The USERTRUST Network, CN=USERTrust RSA Certification Authority"
no IDi configured, fall back on IP address
establishing CHILD_SA vpn{1}
generating IKE_AUTH request 1 [ IDi CERTREQ CPRQ(ADDR DNS) SA TSi TSr N(MOBIKE_SUP) N(ADD_4_ADDR) N(ADD_4_ADDR) N(MULT_AUTH) N(EAP_ONLY) N(MSG_ID_SYN_SUP) ]
sending packet: from 192.168.64.166[55213] to 104.217.249.147[500] (348 bytes)
received packet: from 104.217.249.147[500] to 192.168.64.166[55213] (1248 bytes)
parsed IKE_AUTH response 1 [ EF(1/4) ]
received fragment #1 of 4, waiting for complete IKE message
received packet: from 104.217.249.147[500] to 192.168.64.166[55213] (1248 bytes)
parsed IKE_AUTH response 1 [ EF(2/4) ]
received fragment #2 of 4, waiting for complete IKE message
received packet: from 104.217.249.147[500] to 192.168.64.166[55213] (1248 bytes)
parsed IKE_AUTH response 1 [ EF(3/4) ]
received fragment #3 of 4, waiting for complete IKE message
received packet: from 104.217.249.147[500] to 192.168.64.166[55213] (208 bytes)
parsed IKE_AUTH response 1 [ EF(4/4) ]
received fragment #4 of 4, reassembled fragmented IKE message (3756 bytes)
parsed IKE_AUTH response 1 [ IDr CERT CERT AUTH EAP/REQ/ID ]
received end entity cert "CN=*.pointtoserver.com"
received issuer cert "C=GB, ST=Greater Manchester, L=Salford, O=Sectigo Limited, CN=Sectigo RSA Domain Validation Secure Server CA"
  using certificate "CN=*.pointtoserver.com"
  using untrusted intermediate certificate "C=GB, ST=Greater Manchester, L=Salford, O=Sectigo Limited, CN=Sectigo RSA Domain Validation Secure Server CA"
checking certificate status of "CN=*.pointtoserver.com"
  requesting ocsp status from 'http://ocsp.sectigo.com' ...
nonce in ocsp response doesn't match
ocsp check failed, fallback to crl
certificate status is not available
  using trusted ca certificate "C=US, ST=New Jersey, L=Jersey City, O=The USERTRUST Network, CN=USERTrust RSA Certification Authority"
checking certificate status of "C=GB, ST=Greater Manchester, L=Salford, O=Sectigo Limited, CN=Sectigo RSA Domain Validation Secure Server CA"
  requesting ocsp status from 'http://ocsp.usertrust.com' ...
nonce in ocsp response doesn't match
ocsp check failed, fallback to crl
  fetching crl from 'http://crl.usertrust.com/USERTrustRSACertificationAuthority.crl' ...
  using trusted certificate "C=US, ST=New Jersey, L=Jersey City, O=The USERTRUST Network, CN=USERTrust RSA Certification Authority"
  crl correctly signed by "C=US, ST=New Jersey, L=Jersey City, O=The USERTRUST Network, CN=USERTrust RSA Certification Authority"
  crl is valid: until Mar 26 19:54:53 2022
certificate status is good
certificate policy 1.3.6.1.4.1.6449.1.2.2.7 for 'CN=*.pointtoserver.com' not allowed by trustchain, ignored
certificate policy 2.23.140.1.2.1 for 'CN=*.pointtoserver.com' not allowed by trustchain, ignored
  reached self-signed root ca with a path length of 1
authentication of 'pointtoserver.com' with RSA_EMSA_PKCS1_SHA2_256 successful
server requested EAP_IDENTITY (id 0x00), sending 'My_Personal_ID'
generating IKE_AUTH request 2 [ EAP/RES/ID ]
sending packet: from 192.168.64.166[55213] to 104.217.249.147[500] (92 bytes)
received packet: from 104.217.249.147[500] to 192.168.64.166[55213] (108 bytes)
parsed IKE_AUTH response 2 [ EAP/REQ/MSCHAPV2 ]
server requested EAP_MSCHAPV2 authentication (id 0x01)
generating IKE_AUTH request 3 [ EAP/RES/MSCHAPV2 ]
sending packet: from 192.168.64.166[55213] to 104.217.249.147[500] (140 bytes)
received packet: from 104.217.249.147[500] to 192.168.64.166[55213] (124 bytes)
parsed IKE_AUTH response 3 [ EAP/REQ/MSCHAPV2 ]
EAP-MS-CHAPv2 succeeded: '(null)'
generating IKE_AUTH request 4 [ EAP/RES/MSCHAPV2 ]
sending packet: from 192.168.64.166[55213] to 104.217.249.147[500] (76 bytes)
received packet: from 104.217.249.147[500] to 192.168.64.166[55213] (76 bytes)
parsed IKE_AUTH response 4 [ EAP/SUCC ]
EAP method EAP_MSCHAPV2 succeeded, MSK established
authentication of '192.168.64.166' (myself) with EAP
generating IKE_AUTH request 5 [ AUTH ]
sending packet: from 192.168.64.166[55213] to 104.217.249.147[500] (92 bytes)
received packet: from 104.217.249.147[500] to 192.168.64.166[55213] (332 bytes)
parsed IKE_AUTH response 5 [ AUTH CPRP(ADDR DNS DNS) SA TSi TSr N(MOBIKE_SUP) N(ADD_4_ADDR) N(ADD_4_ADDR) N(ADD_4_ADDR) N(ADD_4_ADDR) N(ADD_4_ADDR) N(ADD_4_ADDR) N(ADD_4_ADDR) N(ADD_4_ADDR) ]
authentication of 'pointtoserver.com' with EAP successful
IKE_SA vpn[1] established between 192.168.64.166[192.168.64.166]...104.217.249.147[pointtoserver.com]
installing DNS server 104.217.249.149 to /etc/resolv.conf
installing DNS server 104.217.249.150 to /etc/resolv.conf
installing new virtual IP 10.255.144.126
selected proposal: ESP:AES_CBC_256/HMAC_SHA2_256_128/NO_EXT_SEQ
CHILD_SA vpn{1} established with SPIs c78f9461_i c2c0f47e_o and TS 10.255.144.126/32 === 0.0.0.0/0
connection 'vpn' established successfully

But after that, all devices connected to the box freeze...

Just in case here is my firewall configuration:

config defaults
       option syn_flood '1'
       option input 'ACCEPT'
       option output 'ACCEPT'
       option forward 'REJECT'
       option disabled '0'

config zone
       option name 'lan'
       list network 'lan'
       option input 'ACCEPT'
       option output 'ACCEPT'
       option forward 'ACCEPT'

config zone
       option name 'wan'
       list network 'wan'
       list network 'wan6'
       option input 'REJECT'
       option output 'ACCEPT'
       option forward 'REJECT'
       option masq '1'
       option mtu_fix '1'

config forwarding
       option src 'lan'
       option dest 'wan'

config rule
       option name 'Allow-DHCP-Renew'
       option src 'wan'
       option proto 'udp'
       option dest_port '68'
       option target 'ACCEPT'
       option family 'ipv4'

config rule
       option name 'Allow-Ping'
       option src 'wan'
       option proto 'icmp'
       option icmp_type 'echo-request'
       option family 'ipv4'
       option target 'ACCEPT'

config rule
       option name 'Allow-IGMP'
       option src 'wan'
       option proto 'igmp'
       option family 'ipv4'
       option target 'ACCEPT'

config rule
       option name 'Allow-DHCPv6'
       option src 'wan'
       option proto 'udp'
       option src_ip 'fe80::/10'
       option dest_ip 'fe80::/10'
       option dest_port '546'
       option family 'ipv6'
       option target 'ACCEPT'

config rule
       option name 'Allow-DHCPv6-Relay'
       option enabled '1'
       option target 'ACCEPT'
       option src 'wan'
       option proto 'udp'
       option dest_port '547'
       option family 'ipv6'

config rule
       option name 'Allow-MLD'
       option src 'wan'
       option proto 'icmp'
       option src_ip 'fe80::/10'
       list icmp_type '130/0'
       list icmp_type '131/0'
       list icmp_type '132/0'
       list icmp_type '143/0'
       option family 'ipv6'
       option target 'ACCEPT'

config rule
       option name 'Allow-ICMPv6-Input'
       option src 'wan'
       option proto 'icmp'
       list icmp_type 'echo-request'
       list icmp_type 'echo-reply'
       list icmp_type 'destination-unreachable'
       list icmp_type 'packet-too-big'
       list icmp_type 'time-exceeded'
       list icmp_type 'bad-header'
       list icmp_type 'unknown-header-type'
       list icmp_type 'router-solicitation'
       list icmp_type 'neighbour-solicitation'
       list icmp_type 'router-advertisement'
       list icmp_type 'neighbour-advertisement'
       option limit '1000/sec'
       option family 'ipv6'
       option target 'ACCEPT'

config rule
       option name 'Allow-ICMPv6-Forward'
       option src 'wan'
       option dest '*'
       option proto 'icmp'
       list icmp_type 'echo-request'
       list icmp_type 'echo-reply'
       list icmp_type 'destination-unreachable'
       list icmp_type 'packet-too-big'
       list icmp_type 'time-exceeded'
       list icmp_type 'bad-header'
       list icmp_type 'unknown-header-type'
       option limit '1000/sec'
       option family 'ipv6'
       option target 'ACCEPT'

config include
       option path '/etc/firewall.user'

config rule
       option src 'wan'
       option dest 'lan'
       option proto 'esp'
       option target 'ACCEPT'

config rule
       option src 'wan'
       option dest 'lan'
       option dest_port '500'
       option proto 'udp'
       option target 'ACCEPT'

Hope someone can help.
Thanks

leftsubnet is not configured, so OpenWrt doesn't tunnel traffic from the lan. But if the provider is not aware of that, it won't work anyway.

Hey @trendy,

Thanks for your answer.

Would it be possible to detail a little more your answer?
Ok, leftsubnet is not configured so what should I do now? Create a new interface or maybe add some rules in the iptables?

Thanks.

I am not very familiar with IPSEC in OpenWrt, however there is analytical guide.
Also you need to allow the firewall rules to the device and not from wan to lan. The leftdubnet normally is your lan which is supposed to be encrypted. But if the VPN provider only allows you a single device, then you'll have to look at masquerading in the firewall. An unmanaged interface is described in the tutorials as the go-to solution when it comes to ipsec.

I have same issue on OpenWrt 21.02 and 22.03, when connection established - all freeze, but from server i can access router web GUI, how to resolve it?

If you're running the original IPSEC "policy based" system (not to be confused with the policy based routing package), setting rightsubnet to 0.0.0.0 means that every request from the client to any destination IP will be encrypted and sent toward the server. So the server needs to be ready to take over the whole Internet for the client.

For a site to site use case where only some subnets are to be linked by VPN, the newer "route based" scheme with an xfrm interface is much easier to get a handle on.

1 Like