Auto-VPN/IP changes/Registration (on AWS)

[BarrettLocus]

Couple questions all related.

I have read this - https://documentation.meraki.com/MX/Site-to-site_VPN/Automatic_NAT_Traversal_for_Auto_VPN_Tunneling_...

I'm trying to figure out if I have options besides using Elastic IP (Which are limited in quota) and I realized I have a few holes in my mental model of the way Auto-VPN works especially with the cloud.

1. How does Auto-VPN handle the change of WAN IP of a VMX? I haven't found good documentation concerning this. Do we have to re-enroll the instance with a new time limited token if the WAN IP changes ?

2. What material is placed on the instance after the time-limited enrollment token expires? Is the identity of an instance established simply use the (WAN IP, SOURCE PORT) that was used to enroll?

3. If my instance dies, but another one is launched, how will it recover the registration/connection.Assuming EIP usage, how would it know what source port to use? In other words, if I attach another instance to the same EIP used to register, then what happens?

4. On AWS, is there any other option besides using Elastic IP's per VMX instance? I understand how the whole punching works, but the issue is the dynamic source port used. If we could select the source port then I believe I could put my instances behind a load-balancer and then target instances based off the port. That doesn't seem like an option.

[PhilipDAth · Accepted solution]

You can use a dynamic or elastic IP.  Both work fine for AutoVPN.

The VMX regularly registers the current public IP address it has in the VPN registry.  So the public IP can change and it is not a big deal.  When spokes connect they look up this IP address in the VPN registry.

So if the public IP address changes - you don't need to do anything - and it will just work.

The token is a one-time use thing used to register with the Meraki portal.  Once registered, it is not used again.

[BarrettLocus]

Thank you for your follow up. I appreciate.

I'd like to get a bit more clarity, just so I fully understand.

The VMX regularly registers the current public IP address it has in the VPN registry. So the public IP can change and it is not a big deal. When spokes connect they look up this IP address in the VPN registry.

Is there some kind of material that the VMX receives that allows it to do this? Meaning once the instance has registered and the token has expired, what allows the VMX to update it's IP. I think I was assuming that identity was established in the following way

1. VMX -> identified by token.
2. VMX registers -> identified by (ip, port)

But if the IP can change that must not be it? As part of the keep-alive/heartbeat messages, is some sort of short-lived token being maintained?

For the case where the instance is lost (say the AZ is down), is it required to re-register with a token then? I'm assuming the VMX100 appliance doesn't allow for backing up Authentication material directly. Is there any known issue with using EC2 snapshots for this?

[TheHype]

---

The VMX regularly registers the current public IP address it has in the VPN registry. So the public IP can change and it is not a big deal. When spokes connect they look up this IP address in the VPN registry.

Is there some kind of material that the VMX receives that allows it to do this? Meaning once the instance has registered and the token has expired, what allows the VMX to update it's IP. I think I was assuming that identity was established in the following way

1. VMX -> identified by token.
2. VMX registers -> identified by (ip, port)

But if the IP can change that must not be it? As part of the keep-alive/heartbeat messages, is some sort of short-lived token being maintained?

---

The authentication information to the cloud is stored on the instance after it authenticates to the cloud with the token for the first time. I'm not sure where, or in what format, as its impossible to log into being a managed instance.

For the case where the instance is lost (say the AZ is down), is it required to re-register with a token then? I'm assuming the VMX100 appliance doesn't allow for backing up Authentication material directly. Is there any known issue with using EC2 snapshots for this?

---

Speaking from an azure point of view, (I assume its similar with EC2)  being a managed instance, they don't really allow for you to do a whole lot with the instance itself, which, is understandable, it'd be allowing a view into how they are running things, and amplify the potential for attacks. Same thing with the backups, I doubt they allow it because they wouldn't want the backup to be reverse engineered.

If the instance is deleted, then yes, the token would have to be re-entered because however they store the authentication to the cloud would be lost at that point. 

[PhilipDAth]

>Is there some kind of material that the VMX receives that allows it to do this?

All physical MX have a certificate burned into them for authentication to the dashboard.

I don't know this for a fact, but I would expect the VMX uses the token to check into the dashboard once to get a certificate to identify it in all future communications so that after deployment it works just like a physical appliance.

You can not backup a VMX in either AWS or Azure.  The permissions do not allow it.  If the AZ is down - no big deal, once the AZ comes back up again you can just start the VMX again and it will use its existing certificate store on its hard drive.

If the actual VMX instance is lost you'll need to delete and re-add the VMX from the dashboard, and re-deploy using a new token.

[BarrettLocus]

If the AZ is down - no big deal, once the AZ comes back up again you can just start the VMX again and it will use its existing certificate store on its hard drive.

My thought was if the AZ/Region is down for an extended period and we want to fail-over and instance without involving a human AND without having cold  standby instances e.g some kind of floating instance/license situation.

In any-case this thread answered my original questions. Thank you.

[PhilipDAth]

You can't create an EC2 snapshot of the VMX.  You don't have permission in AWS to do this.