Hub and spoke supposed to tunnel all but still seeing traffic in event log from spoke being blocked

Solved
from_afar
Getting noticed

Hub and spoke supposed to tunnel all but still seeing traffic in event log from spoke being blocked

I have a hub and spoke set up with one hub and one spoke. I thought I had set everything up so that all traffic would egress WAN1 (unless failover) of the hub. However, when I look at the event logs for the spoke location I can still see a lot of entries of content filter blocking. 

 

The SD-Wan is set up in a single LAN hub-and-spoke configuration; load balancing is disabled; Active-active autoVPN is disabled; and there are no Local Internet breakout rules defined. 

 

Am I mis-reading things? Does the fact that there are entries in the event log for that location not necessarily mean there is traffic exiting to the internet from that location and it is just blocking there instead of at the hub? I did set up content filtering on the spoke device just in case traffic got out that way, but I expected that the actual filtering would all take place on the hub where the actual traffic was hitting the internet. 

 

As a test I added a domain to the whitelist on the hub that someone at the spoke needed to access and after a few minutes, they still could not reach the site and I could see the entries of the blocking in the event log in their location so I think that proves that they are indeed able to get to the internet directly and it's not just pre-filtering on their device and still exiting the hub. 

 

Have I missed some config somewhere that would force all of the SD-Wan spoke/branch traffic to exit through the hub?

 

Thanks.

1 Accepted Solution

But in my understanding this does not mean that if you have a blocking rule created in Spoke that it will not block. Even though you have the default route pointing to the Hub, the rules configured in Spoke are still taken into account.

 

In other words, if you have content filtering enabled at the spoke location, it will block traffic at the source, regardless of the SD-WAN configuration.

I am not a Cisco Meraki employee. My suggestions are based on documentation of Meraki best practices and day-to-day experience.

Please, if this post was useful, leave your kudos and mark it as solved.

View solution in original post

8 Replies 8
alemabrahao
Kind of a big deal
Kind of a big deal

Default Route

When configuring hubs for a spoke, there is an option to select a hub as a Default route. If this option is selected, then that hub will be configured as a default route for the spoke (0.0.0.0/0). Any traffic that is not sent to a configured VPN peer network, a static route or local network will be sent to the default route. This routing will apply to any traffic originating from subnets set to, "In VPN" or that have VPN mode "Enabled."  Subnets that have VPN mode "Disabled" will not adhere to the VPN routing tables. Multiple hubs can be selected as default routes. Hubs marked as default routes take priority in descending order (first priority at the top).

 

 

https://documentation.meraki.com/MX/Site-to-site_VPN/Site-to-Site_VPN_Settings#:~:text=When%20config...

 

I am not a Cisco Meraki employee. My suggestions are based on documentation of Meraki best practices and day-to-day experience.

Please, if this post was useful, leave your kudos and mark it as solved.

Thanks for the reply.

 

The setup is very simple: just the one hub and one spoke. I indeed do have the hub configured with the IPv4 Default route checkbox checked:

 

Screenshot 2024-02-07 at 8.24.24 AM.png 

 

The Main subnet at the spoke location does have VPN mode enabled as I was connecting there to do some testing. Should this be disabled? Nobody needs to VPN in to the spoke location so it's not needed except for testing. 

 

Edit: actually, to test, I just VPN'd into that location and when the VPN  is active, checking my IP address shows the correct HUB IP. Would the AnyConnect VPN be different than the SD-wan?

According to the document, you need to add Spoke networks to participate in auto VPN, otherwise the route will not be added to the routing table.

I am not a Cisco Meraki employee. My suggestions are based on documentation of Meraki best practices and day-to-day experience.

Please, if this post was useful, leave your kudos and mark it as solved.

But in my understanding this does not mean that if you have a blocking rule created in Spoke that it will not block. Even though you have the default route pointing to the Hub, the rules configured in Spoke are still taken into account.

 

In other words, if you have content filtering enabled at the spoke location, it will block traffic at the source, regardless of the SD-WAN configuration.

I am not a Cisco Meraki employee. My suggestions are based on documentation of Meraki best practices and day-to-day experience.

Please, if this post was useful, leave your kudos and mark it as solved.
ww
Kind of a big deal
Kind of a big deal

Only  the normal firewall is bypassed for vpn destinations. 

Content filter, ips still works local

GreenMan
Meraki Employee
Meraki Employee

You may also still have traffic breaking out locally for any VLANs which have VPN disabled;   these VLANs have no access to any tunnels, so traffic sourced there (if it's not going to another local VLAN) will NAT out of the WAN interface, regardless of the default route configured on your tunnel.   @alemabrahao is correct;   content filtering will (only) happen on the local Spoke, as per:  https://documentation.meraki.com/MX/Content_Filtering_and_Threat_Protection/Content_Filtering_and_Th...

Thanks for the reply. 

 

As mentioned, this is a super-simple setup--just the one hub and one spoke and configured as "single lan", so not using any VLANs outside of that. Sounds like I'm just seeing the content filtering happening on the device being logged and the traffic is flowing as expected. 

GreenMan
Meraki Employee
Meraki Employee

Yep, given the available info, I would say so  👍

Get notified when there are additional replies to this discussion.
Welcome to the Meraki Community!
To start contributing, simply sign in with your Cisco account. If you don't yet have a Cisco account, you can sign up.
Labels