- Products
- Learn
- Local User Groups
- Partners
- More
Introduction to Lakera:
Securing the AI Frontier!
Quantum Spark Management Unleashed!
Check Point Named Leader
2025 Gartner® Magic Quadrant™ for Hybrid Mesh Firewall
HTTPS Inspection
Help us to understand your needs better
CheckMates Go:
SharePoint CVEs and More!
Hello,
Would like to know if it is possible with a 1500 device to route FQDN. Would like to have 1 Public IP Address but route (NAT) different FQDN to internal IP Addresses.
If not possible using R81.10 which devices (FW), can be used?
Thanks,
Jeff
You create an object of type Domain.
It can be done while creating the manual NAT rule like so:
R81.10.05 for Quantum Spark Appliances:
In Updatable objects and FQDN in Locally Managed mode (NAT / SSL / Threat Prevention) - Use fully qualified domain name (FQDN) object in the NAT policy, Threat Prevention, and SSL exceptions.
Thanks for the quick reply,
we are using FW R81.10.07, is there some directions how to put the FQDN in NAT?
Greets,
Create the relevant object, create a rule involving it?
phoneboy.com here is an object of type Domain.
That would exactly be my question, how to put a FQDN in "original Destination" in your screen shot it is phoneboy.com how is that created?
You create an object of type Domain.
It can be done while creating the manual NAT rule like so:
I tried that but how to make a reference to the internal IP Address? The Internal DNS Server does refers to the Privat IP Address however coming from outside it is not being sent to the Internal IP. In Network objects is the FQDN ftp....com as domain name, and have NAT Rule any; ftp...com; any; Original; Original;Original
Also tried Translated Destination to Internal IP but does not cooperate either.
To get the internal FQDN, you will need to configure the gateway to use Internal DNS servers, not the external one.
If this isn't working with an internal IP (i.e using a host object), then we need to see more about the configuration including a simple network topology and the precise configuration made (with sensitive details redacted).
Note if you are using the firewall's external IP for inbound communication, do not create a NAT rule, use a Server object instead.
Hello to all hope everyone is healthy, sorry for not replying sooner seems more work than play right now. Assume the same for you all.
First of all we always configure the firewall to use internal DNS Servers, particularly for Remote users. The FW, when pinging the FQDN returns the correct internal IP Address.
Regarding NAT we have added manually rule:
Source = any; Destination = FQDN; Service=any; Translated source = Orginal; Translated destination = FQDN; translated service= orginal
We are running R81.10.07 (996001430) FW
Hope to find a solution, probably something simple that I am missing.
Thanks
You have the same destination for the original and translated packet.
You will need to use the external IP (or an FQDN that resolves to the external IP) as the destination IP.
I think i missunderstand something, the objective is to use 1 public IP Address, however when externally the url is put in, for example, ftp.y-it.net that should go to the internal server ftp.y-it.net when, from extern the url www.y-it.net then that should be routed or Nated to a different internal server. If we put in the orginal destination the Public IP everything will go to the one server, whether using domain name (using the Internal DNS Servr), or IP Address is irrelevant.
presently, for example putting in the url www.y-it.net it goes to the correct Public IP Address, however the Firewall does not send it to the proper internal IP Address.
Is this IP the external IP of the gateway?
In this case, you will need to create one or more server objects instead of NAT rules.
If this is not the external IP of the gateway, then you will need to create more specific NAT rules (based on connection port).
Note that if two or more such servers require the same port (e.g. you've got www.y-it.net and www2.y-it.net using HTTPS), this isn't supported and will not work.
Yes thank you very much for the info this is exactly what I wanted to know. However I do not understand why this should not be possible to route or NAT using FQDN instead of IP Addresses. This would be a very simple change and an improvement. Using the Domainname setting in Objects is really so not of an use.
BTW in this particular case we are using 2 Internet connections, one is SDSL with 5 Public IP Addresses for hosts which can easily be NATed using the Servers setting, and an addtional VDSL connection with 1 Public IP Address.
Would still strongly recommend the change for Checkpoint to be able use DNS for routing and NAT.
I should explain, I know the Internet works using IP, however in the header is also the FQDN request.
This may be possible if the device is managed by a Smart-1 device (i.e. not through the local WebUI).
More precisely, this requires inbound HTTPS Inspection since almost all web traffic is TLS encrypted these days with a certificate that matches all the possible websites (can be a wildcard).
Without this, it is impossible to see the relevant headers to act on them.
This definitely won't work with unencrypted HTTP traffic as that requires functionality that doesn't exist in the products (SMB or otherwise).
Unfortunately, Inbound HTTPS Inspection is not available for locally managed SMB devices: https://support.checkpoint.com/results/sk/sk178604
Thanks for the info, actually this was my very first question: "If not possible using R81.10 which devices (FW), can be used? "
If it is possible using managed Software what are the requirements, and https inspection?
It should be possible with your existing appliance if it is managed with a Smart-1 (Cloud).
This will also require configuring Inbound HTTPS Inspection, which will require a wildcard certificate.
Leaderboard
Epsum factorial non deposit quid pro quo hic escorol.
User | Count |
---|---|
13 | |
3 | |
3 | |
1 | |
1 | |
1 |
Tue 07 Oct 2025 @ 10:00 AM (CEST)
Cloud Architect Series: AI-Powered API Security with CloudGuard WAFThu 09 Oct 2025 @ 10:00 AM (CEST)
CheckMates Live BeLux: Discover How to Stop Data Leaks in GenAI Tools: Live Demo You Can’t Miss!Thu 09 Oct 2025 @ 10:00 AM (CEST)
CheckMates Live BeLux: Discover How to Stop Data Leaks in GenAI Tools: Live Demo You Can’t Miss!Wed 22 Oct 2025 @ 11:00 AM (EDT)
Firewall Uptime, Reimagined: How AIOps Simplifies Operations and Prevents OutagesAbout CheckMates
Learn Check Point
Advanced Learning
YOU DESERVE THE BEST SECURITY