Difference with using Domain Name VS Static IP for Firewall devices
SSTC_EW
Newbie ✭
What is the difference in using a domain name (subdomains) on your firewall devices (multiple 10+) verses using a static IP address. Is their any difference to what you can do if you pick one over the other, mainly speaking can you still uses a device-to-device VPN, also would this break any SSLVPN operations.
Right now we are using "unpurchased" IP address for our firewall devices (TZ), and we need to purchase a CA so we can pass a PCI scan. I know if we purchase the IP address (own all right to) we can buy one CA with multiple SANS, however that is a much larger cost that the alternative. The alternative is that we set up the firewalls using subdomains (multiple devices VPN into a main firewall device) so we would buy a Wildcard CA to cover an unlimited amount of subdomains for the single price of only one CA while not needing to buy multiple SANS for every location.
From what I know (not a lot) and what it seams like, is that it would be better for future us (we open a few locations every couple years) if we just assign our firewall devices to use a domain/subdomain.
Answers
Using proper FQDNs is your only option if you must leave HTTPS open to the world for SSLVPN and have to pass PCI scans.
You might even find it makes your life easier one day when a site change IP address; then you don't have to reconfigure the VPN clients.
I am glad to hear that, I am new to the firewall devices and FQDNs, I thought you could link a firewall device with a domain name but our outsourced IT company said that it was an impossible thing to do and only web servers could hold a domain name. Would this be an intensive process to change over to using FQDNs instead of static IP address, I assume we would have to reconfigure the Device-to-Device VPNs with the appropriate (sub)domain names. And is their documentation on how to make this change.
I was only talking about SSLVPN here, not site-to-site. Site-to-site is not SSLVPN.
Yes, site-site can use FQDNs too. I am not sure it's relevant though, I've never used a certificate for a site-site IPsec tunnel.
Once you need more than a handful of SANs then a wildcard cert is more cost-effective and far more flexible.
Thanks, I am assuming that there is a technical document detailing how to transition to using FQDN. Do you think that it will take a long time to make this transition ( 30+ routers) .
I seem to be missing the point of this conversation. FQDNs are simply human-readable addresses as opposed to IP addresses which are, for most people, harder to remember...
What I think [thought] the point of the conversation is, that you have to leave the SSLVPN login port open to the world to be useful for VPN clients to connect to. If you don't have a "trusted" third-party certificate in use for the service, then some pen testing tools/services will interpret that as a defect/vulnerability. You cannot get a third-party certificate for an IP address, only an FQDN, so the OP is asking about how that would be implemented.
There won't be a document specifically for this operation. You just need to create an A record for every relevant public IP, then make the change from IP to FQDN in every relevant place [ie, on the VPN clients for SSLVPN, and on the site-sites policies for IPsec tunnels].
As to how long? If you're using a wildcard cert then I would estimate about 15 minutes per firewall to import it, apply it and test it. I think you'll need a reboot if the cert you're installing isn't signed by a CA that the firewall already knows about, because importing an additional CA cert requires a reboot.