Inbound allowing of FQDNs

ktv-meraki
Getting noticed

Inbound allowing of FQDNs

I know this comes up a lot, but I still struggle with making sure our services will work.  With Meraki blocking all inbound traffic by default, how can I go about making sure a long list of FQDNs wont potentially get blocked?  We are implementing a new cloud voice contact center solution and the provider gave us a list of 70+ FQDNs that they say must be allowed.  I called Meraki support and we discussed the new Early Access feature called NAT Exceptions with Manual Inbound Firewall.  Aside from some new feature set that I am not familiar with, what do other admins do in these situations?

 

 

10 Replies 10
alemabrahao
Kind of a big deal

If I were you, I would first perform a proof of concept by placing another MX on the bench and configuring a new network to test everything you need to validate.

One question: does the URL allow list not work for you?

 

https://documentation.meraki.com/MX/Content_Filtering_and_Threat_Protection/Content_Filtering

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.
ktv-meraki
Getting noticed

Thank you for your reply.  The project is set to begin so not everything has been tested or validated.  I was trying to get ahead of the request.  We do use Cisco Umbrella and I did create a long Allow List in there for all of them.  That is as far as I have gotten. 

alemabrahao
Kind of a big deal

But I don't know exactly what application you're going to work with this provider, but if we think about security and it really needs to access your internal resources, I wouldn't use NAT and would consider using a site-to-site VPN with them.

Now, if your network is going to access services that are published to the internet in their cloud, there's no need to create anything additional, unless you have some rule that restricts outbound access to the internet.

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.
PhilipDAth
Kind of a big deal
Kind of a big deal

I back @alemabrahao .  I would not sign any contract until a POC has been done and the solution proven to work.

Mloraditch
Kind of a big deal

Usually those sort of lists from vendors, especially a cloud vendor are just URLs/IPs you need to bypass in your content filtering solution and perhaps allow outbound in your firewall rules.

Meraki, like most firewalls, is stateful, if you initiate an outbound connection somewhere, inbound traffic for that connection will work.

Unless a vendor needs to actually access some sort of device on site via NAT, there usually isn't a need for a specific inbound NAT/rule.

Generally I recommend doing the outbound rules if your environment needs them and testing to see if things works. Most of the time they will.

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.
ktv-meraki
Getting noticed

Thank you for your responses, greatly appreciated.  Sounds like I'm off to a good start with an Umbrella list for DNS/Content.  If you are curious, I've attached the requirements.  Look at that long list.2025-04-02_10h23_25.png2025-04-02_10h23_44.png2025-04-02_10h23_57.png2025-04-02_10h24_08.png2025-04-02_10h24_19.png2025-04-02_10h24_30.png2025-04-02_10h24_37.png

Mloraditch
Kind of a big deal

I can't  be sure this is the specific flavor of CXOne we have, but we use CXOne for our Contact center users and we are all remote and have not had any issues with the myriad of firewalls our employees have at home. You should hopefully be good with what you have done.

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.
ktv-meraki
Getting noticed

That sounds exactly like our environment and implementation.  Appreciate you all taking a look at my post.  

ga123456
Conversationalist

I would definitely test things out in a lab first before deploying to any production networks. While NAT Exceptions with Manual Inbound Firewall is Early Access, it's been around for a good amount of time and works well. I've got both the NAT Exception and Inbound FW features configured for a customer and they are working well for us. 

 

In your case you could leave the NAT Exceptions as default and only configure the inbound FW since that is the feature you require. 

 

You can either add your FQDN as a policy object under "Organisation > Configure > Policy Objects" or add it to the rule directly. I created a policy object for each FQDN for easier management and visibility, you can then group them together based on service, region or whatever makes sense to you. If you have a lot to add, definitely use the API Create Organization Policy Object - Meraki Dashboard API v1 - Cisco Meraki Developer Hub

 

From there you reference those in your firewall policy "Security & SDWAN > Configure > Firewall" under Layer 3 Inbound rules.

 

Made-up Example:

Action - Description - Protocol - Source - Src Port - Dest - Dest Port

Allow - Example to HR - TCP - *.example.com - Any - 192.168.1.0/24 - 443

 

ktv-meraki
Getting noticed

Thank you for that write up!

Get notified when there are additional replies to this discussion.