Use FQDNs or policy objects in port forwarding rules

[JWvE]

Hi, we are looking for a way to use policy objects and FQDNs in our port forwarding rules. Is there any news on when this will be supported? In an ever more dynamic world where static IPv4 addresses are no longer the norm and IPv6 adoption is increasing, listing a number of IP addresses is not working any more. It needs to be more intelligent than that.

I read somewhere about a beta feature: custom layer 3 inbound firewall rules. Will that cover what we would like. 

And somewhere else I encountered a discussion where someone suggested that you could use policy objects in port forwarding rules when you add those through the API. I am curious to know if that would work and how that will look in the Dashboard.

Please share your thoughts,

JW

[GIdenJoe]

Hey, I have not seen anything about allowing inbound FQDN's which would not even work in the way fqdn's are used today since they require a DNS request from an internal client to be made through the MX to resolve the address.

I'm however with you in allowing for policy objects to be used in port forwarding rules.  Come on Meraki give use the feature;)

[PhilipDAth]

I can't see FQDN filtering on port forwarding happening.  As @GIdenJoe says, the current engine works on intercepting DNS requests.  It would have to change to proactively do the DNS query and repeat it whenever the TTL was nearing expiring.  That is quite a code change.

10 years ago, port forwards was really common.  Every customer had them because they had servers on-premise.  These days, I'm going to guess only 10% of our customers use port forwards now.  Now most things have moved to the cloud (completely removing the need), or people have change to using client VPN.

Perhaps you could engineer out the need for a port forward?

[GIdenJoe]

Alot of small business providers still like push for portforwarding like for some software that still requires an internal FTP server which is always fun to do on Meraki.  Or the good old provider that installs gear they want to manage remote and don't want to be arsed with setting up client VPN...  Or even worse a provider that does want to manage via VPN but they insist on site 2 site VPN using 192.168.1.0 or 192.168.0.0 as their subnet.

The world is not a perfect place 😉

[JWvE]

I mostly understand what you are saying about the move from on prem to the cloud. We provide however services to our clients that moved their servers from on prem to our datacenter and now the move is from our private cloud to the public cloud. We have less racks in our datacenter than we had before, but we still host management portals, knowledgebases, terminal servers, databases. legacy applications for hotel chains, etc. The people that need access to these servers are not necessarily our own users, we do not manage the devices that they are using, we cannot easily authenticate their acccounts with an identity provider for SAML, MFA or some kind of SSO, etc.

Using client VPN is opening up a whole can of worms at least before Meraki started to support Cisco AnyConnect. Site to site VPN is sometimes an option, but setting up tunnels between firewalls from different manufacturers where we manage only one tunnel endpoint is not very much fun either.

We can certainly engineer our way out of this by using WebRTC, ZeroTier (great concept!) or Cisco AnyConnect, etc. which is obviously better. I mean, in the end this IP whitelisting thing is based on the wrong assumption that an IP address tells you something about an identity that is authorised to access the application, but one should not use an IP address as a means of authentication. But sometimes it helps to have an additional layer of security especially for ugly things like web interfaces for CCTV systems, etc. And than you would really need to use FQDNs of policy objects to prevent you from changing the port forwarding rule everytime an IP address changes. 

What I do not understand is what you are saying about the impossibility to use FQDNs because of the way the engine works or that an internal client is supposed to make a DNS query first. Using policy objects or using FQDNs is the same thing if the policy object is a FQDN. And for outbound rules the policy objects are already supported, so the MX already is doing DNS queries and it needs to repeat these queries every now and then. 

Let me give you an example of what I would like to build in case I was not clear. We have a CCTV system and only security needs access to it from home their homes. So I create two policy objects, securityperson01.company.com and securityperson02.company.com and I put these two policy objects in a policy object group. And I create a port forwarding rule with the policy object group as 'allowed remote IPs'. 

I tell security person 01 and security person 02 to use something like DynDNS and give me their dynamic FQDNs. I create two CNAME records in the domain company.com where securitperson01.company.com resolves to the CNAME of the dynamic FQDN of security person 01 and I do the same for the other one. Now everytime the IP address changes of one of the members of the security team they are still able to access the CCTV system. And when one of the security team members leaves the company, I delete his or her DNS record. 
So I create a 

[GIdenJoe · Accepted solution]

I think you misunderstood the explanation how FQDN objects works.
So it is true that an FQDN policy object just references an FQDN.

But the MX itself will not resolve DNS entries on it's own to map to IP addresses.  It has to see a DNS request from a client behind the MX going out to the internet and being responded to by the DNS server to snoop the entry and put it in a DNS to IP table to dynamically apply to outgoing traffic.  You can find proof of this operation here: https://documentation.meraki.com/MX/Firewall_and_Traffic_Shaping/MX_Firewall_Settings#FQDN_Support

There is no ready made solution for your use case as it stands today when using port forwarding.

However there may be an API solution for this but you would have to determine if this is feasible.

You could have a script on a host inside your DC that does all the DNS querying for you and keeps track of changes in host to IP mappings.  Then when an IP changes you could use the dashboard API to write those changes to the port forwarding configuration.

If you want to go the Anyconnect route, this could be an easier solution by implementing radius authentication so your customers can call in and get access to their machines only.