Connection of a Server to the home network via Strongswan (received INVALID_ID_INFORMATION error notify)

strongswanvpn

I try to establish a VPN connection from my root server to my home network via strongswan. I've configured my router (FritzBox 7490) for VPN PSK XAUTH connections. A VPN connection from my Android-Smartphone works.

I am struggling with the correct configuration of strongswan. I studied the manual and I am getting out of ideas. I am not even sure how to interpret the log.

The two configuration files and the log are:

/etc/strongswan/ipsec.conf

#/etc/strongswan/ipsec.conf
config setup
        uniqueids=no
        #charondebug="ike 4, knl 4, cfg 4, mgr 4, chd 4, dmn 4, esp 4, lib 4, tnc 4"

conn %default
        ike=aes256-sha-modp1024!
        esp=3des-md5!
        ikelifetime=60m
        keylife=20m
        rekeymargin=3m
        keyingtries=1
        keyexchange=ikev1

conn wb
        auto=add
        aggressive=yes
        xauth_identity=montblanc
        left=5.196.66.46
        leftid=keyid:montblanc
        leftsourceip=%config4
        #leftgroups2=montblanc
        #leftfirewall=yes
        leftauth=psk
        leftauth2=xauth
        right=nanga.no-ip.biz
        rightid=%any
        rightsubnet=192.168.178.0/24
        rightauth=psk

/etc/ipsec.secrets 

# /etc/ipsec.secrets - strongSwan IPsec secrets file
%any : PSK "something"
montblanc : XAUTH "somethingelse"

Log when connecting:

initiating Aggressive Mode IKE_SA wb[3] to 93.104.35.40
generating AGGRESSIVE request 0 [ SA KE No ID V V V V ]
sending packet: from 5.196.66.46[500] to 93.104.35.40[500] (341 bytes)
received packet: from 93.104.35.40[500] to 5.196.66.46[500] (412 bytes)
parsed AGGRESSIVE response 0 [ SA KE No ID HASH V V V V V NAT-D NAT-D ]
received XAuth vendor ID
received DPD vendor ID
received NAT-T (RFC 3947) vendor ID
received draft-ietf-ipsec-nat-t-ike-03 vendor ID
received unknown vendor ID: a2:22:6f:c3:64:50:0f:56:34:ff:77:db:3b:74:f4:1b
generating AGGRESSIVE request 0 [ NAT-D NAT-D HASH ]
sending packet: from 5.196.66.46[500] to 93.104.35.40[500] (108 bytes)
received packet: from 93.104.35.40[500] to 5.196.66.46[500] (92 bytes)
parsed INFORMATIONAL_V1 request 3080152599 [ HASH N(INITIAL_CONTACT) ]
received packet: from 93.104.35.40[500] to 5.196.66.46[500] (92 bytes)
parsed TRANSACTION request 3809505870 [ HASH CPRQ(X_TYPE X_USER X_PWD) ]
generating TRANSACTION response 3809505870 [ HASH CPRP(X_USER X_PWD) ]
sending packet: from 5.196.66.46[500] to 93.104.35.40[500] (108 bytes)
received packet: from 93.104.35.40[500] to 5.196.66.46[500] (76 bytes)
parsed TRANSACTION request 3809505870 [ HASH CPS(X_STATUS) ]
XAuth authentication of 'montblanc' (myself) successful
IKE_SA wb[3] established between 5.196.66.46[montblanc]...93.104.35.40[93.104.35.40]
scheduling reauthentication in 3410s
maximum IKE_SA lifetime 3590s
generating TRANSACTION response 3809505870 [ HASH CPA(X_STATUS) ]
sending packet: from 5.196.66.46[500] to 93.104.35.40[500] (76 bytes)
generating TRANSACTION request 835986006 [ HASH CPRQ(ADDR DNS) ]
sending packet: from 5.196.66.46[500] to 93.104.35.40[500] (76 bytes)
received packet: from 93.104.35.40[500] to 5.196.66.46[500] (76 bytes)
parsed TRANSACTION response 835986006 [ HASH CPRP(ADDR DNS) ]
installing DNS server 192.168.178.1 to /etc/strongswan/resolv.conf
installing new virtual IP 192.168.178.202
generating QUICK_MODE request 2471505598 [ HASH SA No ID ID ]
sending packet: from 5.196.66.46[500] to 93.104.35.40[500] (172 bytes)
received packet: from 93.104.35.40[500] to 5.196.66.46[500] (76 bytes)
parsed INFORMATIONAL_V1 request 1883469062 [ HASH N(INVAL_ID) ]
received INVALID_ID_INFORMATION error notify
establishing connection 'wb' failed

I am happy for all suggestions.

Best Answer

When a client receives an INVALID_ID_INFORMATION notification during IKEv1 Quick Mode exchanges it means the responder does not like the contents of the ID payloads, which are used to transmit the traffic selectors (subnets) in these exchanges. This could be because the subnets are not configured correctly (they have to match on both ends). Comparing the configuration and, depending on the implementation, consulting the responder's log might help.

Some IKEv1 implementations use the Cisco Unity extensions, which allow transmitting the tunneled remote subnets during the ModeConfig exchange. Often they then expect the remote subnet in the Quick Mode exchange to be set to 0.0.0.0/0 instead of any of the actual subnets. So try enabling the unity plugin in strongSwan and configuring rightsubnet=0.0.0.0/0, which might be what the responder expects.

Related Topic