On June 30th of this year, 2024, Legacy VPNs connections will be End of Life. This means that all Mulesoft customers still using Legacy VPNs must migrate before that.
If you're new to Mule you probably don't know what we're talking about, which is normal. The current Anypoint VPN that we know is not really a new type of connection created recently.
As a matter of fact, Anypoint VPN was release at the end of 2018 and ever since, all VPN connections have been created as Anypoint VPN.
Before that, creating a VPN connection for Cloudhub was totally different. First of all, the so-called Legacy VPN was not using the AWS Virtual Private Gateway. Secondly, the process was not self-service, as it is now, and it required the help of the Mulesoft Support team. But even if that was a long time ago, there are still some customers that created their VPN connections as Legacy VPNs. This post is for them, we'll try to help them with the migration process to Anypoint VPN.
The first thing you need to know is that the applications deployed to Cloudhub will have no impact. There's no need to change anything or to deploy anything. The migration only requires creating new VPN connections and shutting down the old ones.
Having said that, replacing VPN connections will most likely cause some disruption due to lost of connectivity for the applications deployed to Cloudhub.
To minimize the outage we should follow the next process:
1. Plan your migration
As in any migration, before actually creating or moving anything the first step must be to plan accordingly how you're going to do it and what the process implies to your infrastructure. Some examples:
- How many Legacy VPN connections do we need to migrate?
- Check if you have enough VPN connections in your licence entitlements
- What type of routing (static or dynamic) were the Legacy VPNs using? What type of routing will you be using in the new Anypoint VPNs?
- Measure impact of the disruption - How many of your cloudhub apps use the VPN connection? Is there any timeframe in which you can minimize the impact of losing connectivity?
Check out these series of posts where we explain in detail how to plan a successful migration.
2. Check the requirements and limitations of Anypoint VPN
Mulesoft relies on AWS infrastructure for Cloudhub. The Anypoint VPN is an implementation of a Virtual Private Gateway (VGW) and, as such, you need to be aware of some requirements and limitations.
For example, you need to know that there is a maximum of 10 VPN connections per VPC or that there's also a maximum of 95 entries in the routing table of a VPC.
And in terms of configurations, you need to be aware that Anypoint VPN does not support NAT, IPv6 or Policy-based routing. For a full list of requirements and limitations check the official documentation in here. So, it's always a good idea to check all of this, so that we can foresee any eventual blocker.
Lastly, be aware, as well, that after you create an Anypoint VPN connection:
- You cannot modify the remote IP address or Tunnel configuration (the connection needs to be recreated)
- You cannot modify the routing type or Autonomous System Numbers (ASNs) (connection needs to be recreated)
- You can modify the remote networks. You can add/remove static routes
3. Create the new Anypoint VPN connection(s)
As we mentioned in the intro, the VPN creation is a self-service process, you don't need the Mulesoft Support team.
Depending if you're creating the new connection in Cloudhub 1.0 or 2.0, the VPN creation process is slightly different, with minor differences. There's a couple of articles in this blog for both:
You don't have to shut down the legacy VPNs to create the new connections. Until you establish the encryption domains and the routing you can maintain active your legacy VPNs. Creating the Anypoint VPN connection can take up to 15 mins. This will reduce the downtime and will minimize the non connectivity period to the moment we switch from one to the other.
4. Configure the new Anypoint VPN connection(s)
In order to be able to test the new VPN connections without shutting down the legacy VPN, we recommend setting a /32 encryption domain for a unique host in your network. This will allow us to test the new connection without overlapping with the legacy VPN.
Consider that, when having overlapping:
- if the VPC has multiple routes to the same destination it will use the most specific
- if there are duplicate routes, it will use the manual routes in the old VPN
So, for example, if we need to migrate an encryption domain 192.168.10.0/24 - we can just pick up one host in that subnet for testing, let's say 192.168.10.13 and use a static route of 192.168.10.13/32 in the new VPN connection. This will prevent the overlapping and allow you to test the connection.
5. Configure your VPN endpoint
Use the VPN config file and setup your VPN device
6. Test connectivity
Once the tunnels in your new Anypoint VPN connection(s) are UP, it's time to perform some connectivity tests. For this, the quickest and easiest way to do it is using the Network Tools application. Here you can find a mule app from which you can perform ping, traceroute, nslookup, etc from a graphical interface, super useful.
7. Perform the Cutover
If your tests have been successful it's time for the big moment. For that follow these steps:
- First, select the legacy VPN you want to migrate
- Shut down the tunnels on the old VPN (don't delete them, just disable the routes). If a rollback is necessary, you just need to re-enable the routes. You can leave the legacy VPN running for a few days
- Then set up the encryption domains. Change from /32 to the actual encryption domain. We recommend disabling routes and recreating them in the new VPN, one by one.
- Test the connection for each route/encryption domain
- If everything works then you can Delete your Legacy VPN