Web-server – Manual NAT on Checkpoint (Redirect all http requests to a local web server)

You're getting muddled in your thinking about how information flows between the layers of the TCP/IP protocol stack-- between DNS and application layer protocols, specifically.

You have one public IP address. Your DNS can certainly resolve both mail.example.com and example.com to the same public IP address.

In general, the IP datagrams containing requests to your public IP address, which will be received by the external interface of your firewall, don't contain the name of the host the remote client is attempting to access. Your firewall can't magically "know" which hostname the remote client resolved, since both hostnames resolve to the same IP address. The IP layer isn't aware of the hostname used at the application layer.

The TCP and UDP protocols differentiate specific services offered by a host using port numbers. In the case of your example it may be possible to use the port forwarding (also called port address translation, or PAT) feature of your NAT firewall to send incoming requests to TCP port 80 (HTTP) to the web server while sending inbound TCP port 25 (SMTP) to your email server.

If, however, you plan to host the same service on both machines then this strategy becomes problematic. Suppose you are going to host both a secure web site on your web server (for Customer access) and a secure web site on your email server (for webmail). Requests coming to your NAT firewall's public IP address to TCP port 443 (HTTPS) can only be routed to one server or the other.

The generalized solution to this situation is to have more public IP addresses. Because IPv4 addresses are becoming scarce that can also be problematic.

We end up working around the scarcity of public IP addresses in some protocols at the application layer. For example, HTTP/1.1 added the Host: header specifically to allow a web server to host multiple websites on the same public IP address. TLS adds the Server Name Indication (SNI) extension to allow selection of the appropriate certificate based on the hostname entered by the remote client.

Doing this kind of workaround in the application layer means that every application layer protocol would need its own "fix" (and then all the server and client software would have to implement that "fix"). That's a tall order.

In lieu of modifying the application layer protocol some protocols are easily amenable to being "multiplexed" between multiple hosts using software that can "route" requests. This likely goes beyond what a simple NAT firewall is capable of because the packets need to be inspected at the application layer. Using a reverse-proxy like nginx is a good example of this kind of "multiplexing" (or Web publishing rules on Forefront TMG or ISA Server in a Microsoft environment) for the HTTP protocol. In theory any protocol could be multiplexed via a reverse proxy but the more esoteric the protocol the more likely you'd be talking about having custom code written.

When you need to offer the same service from two different hosts on a single public IP address you always have the option to move one of the hosts to a non-standard port. This will require that clients be aware of the non-standard port, however. In the case of HTTP(S) this results in URLs with the http://example.com:XXX notation (where XXX is the non-standard port number). Whether this would be problematic in your situation is something that only you can decide. (My experience has shown that virtually no end users are capable of handling :XXX port notation in any URL they have to hand-enter.)

You can change the port with static NAT, source and destination. Just look at the NAT tab of the policy and ond the left theres the original packet (the condition that has to match to trigger the translation) and on the right you have the translated packet where you can make the needed changes. So, all you have to to is to create a rule for your special host with static NAT and a second rule with the hide NAT for the other stuff.