vyos charon: 09[IKE] received INVALID_ID_INFORMATION error notify
below is few more lines right before showing that the tunnel is established:
IKE_SA peer-PUBLICIP-tunnel-1[1] established between 192.168.1.30[192.168.1.30]…PUBLICIP[PUBLICIP]
-vyos charon: 11[IKE] scheduling reauthentication in 27730s
-vyos charon: 11[IKE] maximum IKE_SA lifetime 28270s
-vyos charon: 11[ENC] generating QUICK_MODE request 4257237740 [ HASH SA No KE ID ID ]
-vyos charon: 11[NET] sending packet: from 192.168.1.30[4500] to PUBLICIP[4500] (316 bytes)
-vyos charon: 12[NET] received packet: from PUBLICIP[4500] to 192.168.1.30[4500] (76 bytes)
-vyos charon: 12[ENC] parsed INFORMATIONAL_V1 request 3203890434 [ HASH N(INVAL_ID) ]
-vyos charon: 12[IKE] received INVALID_ID_INFORMATION error notify
after this last line I’ll just get a large # of keep-alive packets.
Does anyone have information on this error? I’ve browsed through many many pages of google trying to figure this out and I think I’m going crazy. I see that there is communication between my azure gateway and my VyOS VPN.
Additional information:
vyos@vyos:~$ show vpn debug peer PUBLICIP
I’m not necessarily looking for an answer (if there is one that would be great). Mainly just some tips on what I should be looking for specifically or additional commands for debugging more information.
Hmm. Thanks for the resources I’ll look into those.
right now I have the vyOS router on the residential gateway. Do you think if I instead put 192.168.1.1 (default gateway) into the DMZ instead that may resolve the NAT issue?
You will need do something so that the “NAT Factor” is addressed.
The problem is that IPSEC writes the IP information into the packet itself. NAT comes along and changes the IP source/destination for NAT to work, but it can’t do a rewrite of the data in the IPSEC packet itself (it’s encrypted)
So you end up with an IPSEC that won’t establish.
That’s why you need to look at the NAT Traversal options, or make your Vyos box the box doing the NAT itself so it can listen for IPSEC on the WAN/Public Interface (so that NAT rewrite doesn’t need to happen)
Again my IPSEC is a bit rusty and some of the terminology (or even facts) might be wrong, but Google “IPSEC and NAT” and you’ll soon see what I’m getting at.
I’ve spent quite a bit of time these past few days learning all about the IPSec protocols and RFC 8229 so I definitely have a better understanding now when I’m trying to read through error logs. I just wanted to update you on a small thing. I ended up putting the VyOS option on pause and was able to successfully create a VPN tunnel using RRAS on Windows Server. Would this indicate that problem is likely the configuration on my VyOS appliance? I also now understand what you were talking about in your post about NAT-T. Anyway. Thank you for pointing me in the right direction!
EDIT: I do agree with you. I’m almost certain it is the NAT configuration on the vyOS appliance. I will do some more digging and figure it out.
I have several IPSEC tunnel established behind a NAT and it can work, but it’s a bit tricky.
By default IPSEC peers are identified by their IP address and the NAT changing this IP, the ID doesn’t match. So you have to set an authentication ID to use instead of the IP address.
Here is an example of a configuration that works behind a NAT, altough it is to another VyOs and not to Azure (this is for a VTI based tunnel, but the phase 1 configuration is the same if you use a classical tunnel)
set vpn ipsec ipsec-interfaces interface 'eth0.2098'
set vpn ipsec nat-traversal 'enable'
set vpn ipsec site-to-site peer 203.0.113.17 authentication id '@PCR-R2'
set vpn ipsec site-to-site peer 203.0.113.17 authentication mode 'pre-shared-secret'
set vpn ipsec site-to-site peer 203.0.113.17 authentication pre-shared-secret '<your PSK>'
set vpn ipsec site-to-site peer 203.0.113.17 authentication remote-id '@STD-R5'
set vpn ipsec site-to-site peer 203.0.113.17 connection-type 'initiate'
set vpn ipsec site-to-site peer 203.0.113.17 ike-group 'standard-IKE-group'
set vpn ipsec site-to-site peer 203.0.113.17 ikev2-reauth 'inherit'
set vpn ipsec site-to-site peer 203.0.113.17 local-address '192.168.2.252'
set vpn ipsec site-to-site peer 203.0.113.17 vti bind 'vti2'
set vpn ipsec site-to-site peer 203.0.113.17 vti esp-group 'standard-ESP-group'
Although I don’t know how to set the ID azure side, but it should be an available option.