Turn on suggestions
Auto-suggest helps you quickly narrow down your search results by suggesting possible matches as you type.
Become a member of the Cisco Meraki Community today
Get answers from our community of experts in record time.
Join now- About RCMikesell
About RCMikesell
RCMikesell
Here to help
Member since Sep 10, 2024
2 weeks ago
Community Record
13
Posts
1
Kudos
0
Solutions
Badges
Jun 25 2025
6:38 AM
1 Kudo
Follow up on the situation and its resolution. Meraki was able to determine that the packets were reaching into the network We setup a laptop internally in the network (with client help) that we put Wireshark on We were able to see the pings coming in and being responded to. Pings still not being seen from the VPN client Checked the routing on the laptop and the Gateway was to a different location Thus routing pushed any responses to that Gateway, not the Meraki Added a rule on the laptop to route traffic from the VPN specific IP range and access was gained.
... View more
Jun 16 2025
12:28 PM
Opened a Ticket with Meraki.
... View more
Jun 13 2025
6:06 AM
I did try this as well and the results were the same, so routing out of windows to the MX isn't the issue. I too had first assumed this was the most likely issue at first, but when it didn't work modified my theory.
... View more
Jun 13 2025
12:11 AM
Agreed on packets getting to the MX, but then its going to the WAN rather than the VLAN. This is what has me questioning if the default routing for non RFC1918 addresses to a WAN connection is taking precedence over the Internal address list on the VLAN. The routing table shows no metrics.
... View more
Jun 13 2025
12:06 AM
Your link leads to a list of links... wasn't able to see your information provided there. I did a packet capture on the meraki itself both for VPN interface and LAn interface Both PCAP files showed icmp packets coming into the Meraki from the VPN assigned IP address as source and the internal 100.0.1.1 as destination. I believe this shows that the Client side at least is not dumping/discarding the data packets, they are traversing the tunnel. The MX appears to not be pushing these packets to next hop (which would be 100.0.1.2)
... View more
Jun 12 2025
11:56 PM
Also to note, I did do a packet capture on the Meraki itself testing if the packets were arriving at the Meraki and getting through. I was able to see them arriving.
... View more
Jun 12 2025
11:54 PM
When attempting to access 100.0.1.1 using windows based tracert: Tracing route to lo0-100.BSTNMA-VFTTP-350.verizon-gni.net [100.0.1.1] Comparison: Off VPN: to On VPN:
... View more
Jun 12 2025
11:44 PM
This was from back when I was trying the 192.168.200.0/24 network for the VPN: the 192.168.4.147 is my local IP and the first routing rule but its metric is fairly high compared to the added route pointing to the IPsec interface (at this time) of 192.168.200.155 with its metric of 26.
... View more
Jun 12 2025
11:36 PM
The host routing and internally is: Ver Subnet Nam VLAN NextHop Destina Type 4 100.0.1.0/24 LAN 1 100.0.1.2 100.0.1.2 Local VLAN 100.0.1.2 is the interface IP on VLAN1 in the meraki
... View more
Jun 12 2025
11:35 PM
Some notes on your suggestion: LAN and VPN do not share overlapping subnet address spaces VPN is on 192.168.18.0/24 (also attempted with 192.168.200.0/24) LAN is on 100.0.1.0/24 Would love to re-segment the VLAN, but as its already in production and not my company, likely not a possibility. If I was initially rebuilding the entire network, this would be the solution, but not in this case. VPN Subnet Translation is a Site to Site protocol only, not Client to Site (which is the issue here) This is a good thought, but as its exclusive to site to site, doesn't work in this case I did try setup of a Route Add for the host to point to the Vpn for specific IP subnets This made no difference as the routes on the host already push all traffic to the Meraki (this is default setup and requires changes on the Host interface to split traffic) Enabling the VPN writes a host route of 0.0.0.0 to catch all, and is set at a significantly lower metric so it takes precedence.
... View more
Jun 12 2025
9:35 PM
This is a Meraki MX replacing another brand of firewall. Client has chosen to use the IPSec VPN on the firewall, not wanting to pay for AnyConnect so that option is unfortunately out. - edit: attempted with AnyConnect as well... same issue. VPN is configured with Radius Authentication and DUO mfa It is operating using the Windows VPN and is operating as expected to connect to the site. The problem I fear is the client, far in the painful past, chose to use a Private IP subnet for their LAN Vlan. Config: VLAN 1 is setup as in the 100.0.1.0/24 subnet IPsec VPN is setup with the Private IP subnet 192.168.18.0/24 Layer 3 Rules allow access from the VPN subnet to VLAN 1 Layer 3 Rules allow for any source and destination ports Ipsec is currently setup to forward all traffic over the VPN to the client site (confirmed with show my ip when connected) Pings to the local DNS server do not return from VPN client, but do from MX Tests Client Tracert results show Tracing route to lo0-100.BSTNMA-VFTTP-350.verizon-gni.net [100.0.1.1] Firewall reports and packet captuers show that the Firewall is receiving the packets and that Layer 3 rules are allowing the VPN to access through to 100.0.1.1 Based on this information I believe the MX is routing the traffic destined for the 100.0.1.0/24 subnet to the internet I cannot enter a static route to point to the firewall VLAN ip for the Subnet as it already exists in its routing table Any ideas out there on if there is a way to make this work, the previous VPN on the old firewall allowed for it to work
... View more
Labels:
- Labels:
-
Client VPN
Jan 20 2025
1:36 PM
Blake, I did note that this was "over an existing Site to Site VPN" that we have in place that those guides assist in setting up. That is working without issue. I need to add/update the VPN now to send all internet bound traffic over this same existing VPN and have it reach the internet and allow returns. That said, maybe I may need firewall rules, but as that data is transformed on the SonicWall site using a Nat rule from WAN to WAN I assumed it was allowed traffic. I used these two guides when trying to initially configure and test with just 8.8.8.8 https://www.sonicwall.com/support/knowledge-base/how-can-i-configure-tunnel-all-internet-traffic-over-site-to-site-vpn/170504924710971 https://documentation.meraki.com/MX/Site-to-site_VPN/Site-to-Site_VPN_Settings#Non-Meraki_VPN_peers
... View more
Jan 20 2025
9:47 AM
Looking to build a full tunnel from a meraki at a branch office to send all traffic over an existing Site to Site VPN to a Sonicwall at the main site. Based upon reading the Site-to-site_VPN setup for non-meraki VPNs I believe I should be able to set a 0.0.0.0/0 in the IPSec subnets (I am just doing 8.8.8.8 initially as a test). I am basing the sonicwall side on their "how can i configure tunnel all internet traffic over site to site vpn (170504924710971). When I set this up, I get no return on pings. Has anyone else been able to successfully setup and operate this type of setup? Thanks
... View more
Labels:
- Labels:
-
3rd Party VPN
My Top Kudoed Posts
| Subject | Kudos | Views |
|---|---|---|
| 1 | 2693 |
© 2025 Cisco Systems, Inc.
