Vyos site-to-site tunnel to Azure Resources

Hello forum friends.

I’ve been working on setting up a VyOS site-to-site VPN tunnel to my Azure resource cloud.


  • VyOS running on Hyper-V (has full connectivity to the internet (can ping etc)
  • Residential Gateway has ports 500 and 4500 forwarded
  • put VyOS ip address onto DMZ through Residential Gateway settings

Current situation:

  • show vpn ipsec/ike sa both show that the tunnel is up and I see a continuous stream of keep-alive packets being sent to the Azure VPN gateway.
  • There is no transfer of data though. I can’t actually ping any Azure resources.

show log vpn all has A LOT of information but I think only one line really matters. It’s right before the the keep-alive packets.

  • vyos charon: 09[ENC] parsed INFORMATIONAL_V1 request 1409572031 [ HASH N(INVAL_ID) ]
  • 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[]…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[4500] to PUBLICIP[4500] (316 bytes)
-vyos charon: 12[NET] received packet: from PUBLICIP[4500] to[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

peer-PUBLICIP-tunnel-1: local: [] uses pre-shared key authentication
peer-PUBLICIP-tunnel-1: remote: [PUBLICIP] uses pre-shared key authentication
peer-PUBLICIP-tunnel-1: child: dynamic === dynamic TUNNEL
peer-PUBLICIP-tunnel-1[1]: ESTABLISHED 4 minutes ago,[]…PUBLICIP[PUBLICIP]
peer-PUBLICIP-tunnel-1[1]: IKEv1 SPIs: 56657e4e1c67f1a5_i* 5544b08c9eb81dee_r, pre-shared key reauthentication in 7 hours
peer-PUBLICIP-tunnel-1[1]: IKE proposal: AES_CBC_256/HMAC_SHA1_96/PRF_HMAC_SHA1/MODP_1024

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.

IPSEC tends to hate NAT, and it looks very much like your Residential Gateway is doing NAT for you.

While my reply isn’t very helpful, you could look at this thread and see if there’s anything of use for you.


1 Like

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 (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.

1 Like

Hey tjh,

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.

1 Like

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 authentication id '@PCR-R2'
set vpn ipsec site-to-site peer authentication mode 'pre-shared-secret'
set vpn ipsec site-to-site peer authentication pre-shared-secret '<your PSK>'
set vpn ipsec site-to-site peer authentication remote-id '@STD-R5'
set vpn ipsec site-to-site peer connection-type 'initiate'
set vpn ipsec site-to-site peer ike-group 'standard-IKE-group'
set vpn ipsec site-to-site peer ikev2-reauth 'inherit'
set vpn ipsec site-to-site peer local-address ''
set vpn ipsec site-to-site peer vti bind 'vti2'
set vpn ipsec site-to-site peer 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.

1 Like