Has anyone managed to get client vpn working on aws using vmx?
We are using several vmx for site to site with other vmx's and physical MX's for auto vpn but when I try to setup client VPN I get error 809, I've tried everything I can think of on Meraki and aws to make it work but haven't had any luck so far.
Your most likely hitting a NAT issue so see this link and search error 809- https://documentation.meraki.com/MX-Z/Client_VPN/Troubleshooting_Client_VPN
Depending on what your trying to accomplish this design may not supported beyond intranet (site to site) traffic. vMX VPN concentrators operating within AWS do not support full tunnel VPN. Your not trying to route out through AWS to internet are you?
In full tunnel mode all traffic that the branch or remote office does not have another route to is sent to a VPN hub.
This is not supported for virtual MX VPN concentrators operating within AWS.
Hi D, Thanks for your reply,
I'm simply trying to access a local subnet on aws, I tried the windows 10 registry hack below as suggested which works:
"Client behind NAT devices
Solution: Modern Windows devices do not support L2TP/IPsec connections when the Windows computer or VPN server are located behind a NAT. If the Windows VPN client fails with Error 809 when trying to establish a VPN connection to an MX located behind a NAT, add the "AssumeUDPEncapsulationContextOnSendRule" DWORD value to the Windows registry. This DWORD value allows Windows to establish security associations when both the VPN server and the Windows based VPN client computer are behind NAT devices."
However I don't want to implement a company-wide registry change just because of this, I also don't understand why that doesn't happen when I vpn to the office physical mx not aws from a location such as a coffee shop as I'm also behind NAT in that situation?
It may be an aws setup issue or vmx limitation I've attached a network map below which shows the current setup.
Site to site vpn between physical and aws vmx works fine it's just client vpn to aws vmx.
There is a limitation because internally to the MX the client VPN process is separate from the AutoVPN process and is unable to route between the two. Therefore your not going to be able to route through the same MX when using client VPN to AutoVPN routes in your design.
An option is to have a dedicated MX concentrator in your DMZ. This would allow you to only have one client VPN into your office that would allow you to route through the office for both corp and AWS services. I'm not sure how many clients you have but maybe it could be done with a MX64. I know bringing hardware into the mix isn't always easy but I'm not sure there is any other option this current Meraki design if you do not want to push a registry change.
Sorry perhaps I wasn't clear enough, let's forget auto-vpn between physical sites and AWS as that is working fine.
All I need to do is to be able to access subnet A in AWS using client vpn on windows 10 pro from a remote random location, at the moment I can't even establish the ipsec tunel to the vmx on aws without using the registry hack.
I just noticed ip's for devices were wrong please see below updated network map.
I understood your question. The answer is still the same, if the hack fixes the error your getting that is the only answer I have with the current design/products. I followed up and gave you another option I know will work but requires additional hardware. There may be some other options the other community members can provide using something open-source.
I don't want to access AWS via physical mx in the office I want to go straight to AWS --> Vmx to access aws subnets (non office) thus the solution you suggest would not work.
So I'm I to understand that there is no way to access an aws subnet using client vpn connecting directy to an aws vmx instance without the registry hack?
We were looking at doing the same thing for our network.
Is it possible that you'd be able to use a vMX in AWS as a client VPN gateway in the future?
Or is this because of some limitation that isn't going away?
Reach out to your local SE. We can do this but it but there are some limitations. I wouldn’t go as far as supported but it can be done.