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
... View more
