Client VPN not working on MX67

Solved
rock3t_singh
Here to help

Client VPN not working on MX67

Hello Everyone,

 

I am trying to set up client VPN and have not seen any success with it. My setup is as below:

 

------------------

| INTERNET |<-------->DLINK      G225<----->MX67<------>MS120-8LP

------------------              BRIDGE MODE

 

I have checked all the settings, however, the issue is that I do not see any traffic over ports 500 and 4500 coming in on MX67 in Packet Captures.

 

ISP in question is Aussie Broadband. 

 

Can someone please advise on what can be done further?

 

Warm Regards,

Tajender

 

1 Accepted Solution
Raj66
Meraki Employee
Meraki Employee

@rock3t_singh When you see the public IP and the WAN IP being different, that means your traffic is getting NATTED upstream, even though you have a public IP assigned to your MX. I strongly believe the router with the 100.x.x.x address blackholing the client VPN traffic. 

 

To get further clarification, you can try what is my IP in google and if you see 100.x.x.x, then please give your ISP a call and ask them why your traffic is being NATTED upstream when you have a public IP and also ask them to port forward UDP port 500 and 4500 to the MX for client VPN connection. Once this is done, you need to configure your client VPN for the public IP of 100.x.x.x. since port forwarding is enabled on the 100.x.x.x router, the traffic will be forwarded to your MX and client VPN negotiation will happen.

If you found this post helpful, please give it kudos. If my answer solved your problem, click "accept as solution" so that others can benefit from it

View solution in original post

15 Replies 15
ww
Kind of a big deal
Kind of a big deal

did you configure the dlink for this vpn service? 

rock3t_singh
Here to help

The DLink us in bridge mode already. I believe it is not blocking anything as the firewall would be completely transparent in bridge mode. Is there any other configuration that needs to be done on it?

rhbirkelund
Kind of a big deal
Kind of a big deal

I have a DMZ setting on my home router. From what I understand, when enabling this, and setting the DMZ address, what ever client with that address is in the DMZ of my home router and therefore free of any firewalling.

I couldn’t get my MX to register in the cloud, and a call to my friendly neighbourhood ISP, confirmed my suspicion.

My MX was being firewalled, even though it was put in DMZ. And this was working by design.

 

So, take a look at your DLink, and verify it isn’t firewalling your MX. And afterwards try adding the Meraki Firewall info, that is required for Cloud communication.

LinkedIn ::: https://blog.rhbirkelund.dk/

Like what you see? - Give a Kudo ## Did it answer your question? - Mark it as a Solution 🙂

All code examples are provided as is. Responsibility for Code execution lies solely your own.
rock3t_singh
Here to help

The D-Link router is in bridge mode and is not getting any WAN IP. The MX is getting public IP. 

 

@rhbirkelund in your case, seems like your MX is getting private IP allocated by ISPs router.

PhilipDAth
Kind of a big deal
Kind of a big deal

What error message is the client getting reported?  Anything appearing in the Network-Wide/Event log when a user tries to connect?

 

Check out the client VPN trouble shooting guide.

https://documentation.meraki.com/MX/Client_VPN/Troubleshooting_Client_VPN

BlakeRichardson
Kind of a big deal
Kind of a big deal

At a guess even though the D-Link is in bridge mode that model is a consumer grade modem and is probably doing something silly with VPN traffic. 

If you found this post helpful, please give it Kudos. If my answer solves your problem, please click Accept as Solution so others can benefit from it.
rock3t_singh
Here to help

I am getting error 789 on windows clients and I have followed the troubleshooting steps. However, that didn't yield anything.

 

When I look at Uplink for my MX, I see a public IP and a WAN IP and both are different. Public IP is 180.x.x.x whereas the WAN IP is 100.x.x.x. I can ping the public IP from other hosts, but cannot ping the WAN IP. When I do a packet capture with a continuous ping to 180.x.x.x IP address, I do not see any traffic coming in to my MX even though the ping is successful. The ping to 100.x.x.x anyways fails and is not logged in the pcap.

 

I tried to capture all the icmp traffic with continuous ping to both the ip's running from a PC sitting on internet via 4G/LTE. the only ICMP traffic that I could see was requests being sent to 8.8.8.8 and replies received from it.

 

 

 

 

Ben
A model citizen

@rock3t_singh 

Perhaps traceroute outside from behind your MS120 and see which route it follows outside.

OR

Are u able to ping your dynamic hostname of your MX? You can find it under Appliance Status -> Hostname 

It should be visible under your WAN1 ip. 

 

If this does respond, configure your VPN with the DDNS.

 

 

rock3t_singh
Here to help

The hostname resolves to 180.x.x.x IP and I am able to reach it from outside.

 

Still, I do not see any icmp packets hitting the internet interface when I do a packet capture.

Raj66
Meraki Employee
Meraki Employee

@rock3t_singh When you see the public IP and the WAN IP being different, that means your traffic is getting NATTED upstream, even though you have a public IP assigned to your MX. I strongly believe the router with the 100.x.x.x address blackholing the client VPN traffic. 

 

To get further clarification, you can try what is my IP in google and if you see 100.x.x.x, then please give your ISP a call and ask them why your traffic is being NATTED upstream when you have a public IP and also ask them to port forward UDP port 500 and 4500 to the MX for client VPN connection. Once this is done, you need to configure your client VPN for the public IP of 100.x.x.x. since port forwarding is enabled on the 100.x.x.x router, the traffic will be forwarded to your MX and client VPN negotiation will happen.

If you found this post helpful, please give it kudos. If my answer solved your problem, click "accept as solution" so that others can benefit from it
rock3t_singh
Here to help

In google it shows my ip as 180.x.x.x and not 100.x.x.x.

 

I am also able to ping 180.x.x.x ip from internet.

Raj66
Meraki Employee
Meraki Employee

Interesting! If you are seeing 100.x.x.x as the public IP on the dashboard, that means the Meraki dashboard is seeing traffic coming from this appliance with that IP. Definitely, something funky is going on with NAT upstream (probably only for certain routes and not all as we are seeing 180.x.x.x as public from a client behind MX)

 

That being said, since we are not able to ping 180.x.x.x from your computer, can you do a traceroute from your computer to 180.x.x.x and see where it is getting dropped? Also, it's worth connecting to a different ISP on the client side to check if it will make any difference

 

 

If you found this post helpful, please give it kudos. If my answer solved your problem, click "accept as solution" so that others can benefit from it
rock3t_singh
Here to help

@Raj66 

I see the WAN1 IP and Public IP as 180.X.X.X whereas the IP on the WAN interface is different. Please see the attached screenshot.

 

Meraki-Wan.JPG 

rock3t_singh
Here to help

Thanks a lot for all the advise and help, finally managed to fix it.

 

Apparently turned out that the ISP in this case (Aussie Broadband) uses CG-NAT (https://www.aussiebroadband.com.au/support/knowledge-base/nbn/cg-nat/). Got on a call with them and opted out of CG-NAT and everything came on track. 

Raj66
Meraki Employee
Meraki Employee

Are you able to ping the public IP on the MX from your computer?

A good way to check if UDP 500 and 4500 traffic (needed for client VPN) is getting blocked upstream or not is to take a packet capture on the Internet interface of the MX and do a continuous (ping -t x.x.x.x) from your computer  and try to connect over client VPN simultaneously. If you see only ICMPs in the capture and not UDP 500 and 4500 traffic then it is getting blocked somewhere upstream and it is time to give the ISP a call.

If ping is also not working, a traceroute will give us a pretty good idea about where it is failing.

If you found this post helpful, please give it kudos. If my answer solved your problem, click "accept as solution" so that others can benefit from it
Get notified when there are additional replies to this discussion.