This is a quick blog to get out there what I discovered fixing this issue last week. My work issued me a Meraki Z3 for remote connectivity from home. Although it could talk to the cloud-hosted Meraki dashboard it could not establish the VPN between my house and the office for me to access resources. This confused me because I allow trusted network devices unrestricted access to the internet, so why couldn’t it “dial home” to bring the VPN up?
My IT team was able to inform me the Meraki’s reporting “Unfriendly NAT” on my network and this pointed me in the right direction to get this working with the help of many internet forum posts and hours of trial and error. Everything I read got one thing wrong however (possibly because of the posts age) so I wanted to document that here.
Rather than a traditional VPN host where you open up the ports required for remote end points to dial in and connect the Meraki solution uses a more dynamic method. My limited knowledge of VPN suggests this is actually a more secure method for the VPN host, but I could be wrong. And the word Host here is wrong, as this is effectively two peers negotiating a connection, not a remote endpoint dialing into a VPN host. To achieve this Meraki uses a method called UDP hole punching. They have a really good write-up of this that you should read before continuing with the below – Automatic NAT Traversal for Auto VPN Tunneling between Cisco Meraki Peers – Cisco Meraki
Ok, glad you read that, because it will help you understand the below and apply it to your specific pfSense setup.
By default pfSense masks source ports. If a device chooses source port 41337 outbound pfSense can translate that to anything it wants and tells the internet it really came from, for example, source port 48008. As you understand from reading the above Meraki article, their technology relies on the outbound Meraki connection to open a firewall session or state with the genuine source port chosen by the Meraki, so that the remote Meraki peer can use this to send its data down to the Meraki node behind your pfSense.
All the instructions I saw for this setup on the internet told you to use the cloud management ports like 7361 & 9350, but these are not needed in my experience. The crucial ports to ensure pfSense does not mask is the range the local nodes use for the VPN – 32768-61000 (as specified on that page above).
I’m outta time so here are the pfSense instructions for doing that. I’ve no doubt you could make this more secure, but this works for me on a risk/reward basis.
- [Optional] Go to Firewall>Aliases>Ports and create a port alias for the port range the Meraki uses to establish the VPN. This range is 32768-61000
- This saves no time in the end because it is a single range. I originally thought I needed to allow multiple ranges so went through this step but you can just enter the range in the next steps
- Go to Firewall>NAT>Outbound
- Set Outbound NAT Mode to Hybrid
- this keeps pfSenses automatic rules enabled but the user can add manual rules in addition
- Add a new NAT Mapping:
- Interface: WAN
- Protocol: UDP
- Source: Network + IP of Meraki appliance / 32
- You can add an entire subnet here if you don’t assign a static IP to the Meraki, but this is less secure.
- Adding /32 on the end lets the user specify a specific single IP
- You can also create an IP Alias for this address but it is more steps and saves nothing
d.
- Destination: Any + Port: 32768-61000 (or alias created in Step 1)
- If your company uses static IP’s for the VPN host and you can find them out then you can specify IP addresses here (like done for Source above) to make it more secure, but it risks breaking if the company changes these without telling you. As you’ve already limited it to just the Meraki in Source above the risk is low to allow this to all destinations.
- Creating a port alias for this was as pointless as creating an IP alias for the Meraki but I had already done it expecting to need to allow several port ranges for this to work.
- Address: Interface
- Port or Range: Tick ‘Static Port’
Thanks so much for this, we were really struggling. Saved the day!
Excellent! I’m so glad it saved someone some time. Thanks for letting me know!