hairpin nat many vlans

[Askey_oot]

Hi!

Accroding to sk110019

I create Destination NAT, that I can see oryginally no NATed public IP accessing from Internet to forwarding my web server and this is fine and working simple.

How can I construct a hairpin NAT rule in the following scenario where we need to access from multiple VLANs to a web server where he is place in a different VLAN using a public IP address, but so that the web server logs must show the original IP private address of workstations.

I've try configure hairpin nat rule but only what I can get is all traffic from example vlan is hidden behind gateway and show on logs web server gateway ip address.

Any ideas how to get resolve this scenario?

[the_rock]

I think I saw post about this before, will see if I can find it.

[the_rock]

I found below:

https://community.checkpoint.com/t5/Security-Gateways/NAT-Loopback-Hairpin-NAT/m-p/238179

https://community.checkpoint.com/t5/General-Topics/Hairpin-NAT-is-not-working/m-p/207912

This AI answer seems pretty decent to me:

There are three practical ways to solve this depending on what you can change in your environment. I’ll explain why the gateway SNATs, show the Check Point NAT approach to preserve the original client IP, and then give two safer/cleaner alternatives (and their tradeoffs).

---

Why the server sees the gateway IP

When an internal client connects to the server’s public IP:

• The gateway destination-NATs the destination to the internal server IP.

• If the server replies directly to the client’s private IP (not via the gateway) the TCP conversation breaks (client expected replies from the public IP).

• To make replies return through the gateway (so it can reverse the destination NAT), the gateway often performs source NAT (hide/SNAT) of the client to the gateway IP. That guarantees the server’s reply goes back to the gateway, which then reverses NAT and sends it to the client — but now the server sees the gateway IP as the source.

This behavior and the SK that documents NAT loopback for Check Point are described in SK110019. Check Point Support

---

Option A — Keep the original client IP (Manual NAT + proper routing)

This is the approach that can preserve original client IPs in server logs — but only if the server’s routing forces replies back through the firewall.

Steps (Check Point / SmartConsole manual NAT style):

1. Keep your existing external→internal static NAT that publishes the server on the public IP (so Internet users keep working).

2. Add a Manual NAT rule (place it above the automatic/Global rules) to handle internal clients hitting the public IP:

   • Original Source: <internal_VLAN_subnets> (or an object group containing all VLAN networks)

   • Original Destination: <public_IP_of_server>

   • Translated Destination: <internal_IP_of_server>

   • Translated Source: Original (i.e. do not change the source) — this is the key.

   In SmartConsole the Translated Source column should be set to Original or “No translation” for that traffic.

3. Make sure the server’s return path to those internal VLANs goes through the firewall. Concretely:

   • Server default gateway must be the firewall (or)

   • Add static routes on the server for each client VLAN pointing to the firewall as next-hop.

Why this works: the request arrives at the gateway, destination-NAT translates to the server IP while keeping client source intact; the server replies to the client IP but because the server sends the packets to the firewall (via its gateway or a specific route), replies will traverse the firewall and be handled in the same connection tracking entry — the gateway reverses destination NAT and the client sees responses from the expected public IP while the server saw the original client IP in its logs.

Caveats:

• If the server has a direct route back to a client subnet (i.e., not via the firewall), replies will bypass the firewall and the TCP session will fail. That’s the usual reason admins see gateway IP logged: to force replies back through the gateway the gateway performs SNAT by default.

• If you have many VLANs, you must ensure the server has routes for all of them via the firewall (or the firewall is the server’s default gateway).

• You must place the Manual NAT rule correctly (above auto/Global rules).

Relevant Check Point doc and community posts describing both SK110019 and user experiences. Check Point Support+1

---

Option B — Split-horizon (internal) DNS — recommended where feasible

Instead of forcing hairpin NAT, configure internal DNS so the public hostname resolves to the server’s private IP for internal clients (per VLAN if needed). That is the cleanest solution:

• Clients access the server via internal IP (no hairpin).

• No NAT translation for internal→internal traffic.

• Server logs contain the real client IP.

• No special NAT or routing gymnastics.

Tradeoffs:

• You need to manage internal DNS views (or per-VLAN DNS overrides).

• If you have many VLANs or multiple DNS servers that’s additional administrative work, but it’s the most robust and performant solution.

Many shops prefer split-horizon DNS specifically to avoid hairpin compromises (it’s the usual best practice). Server Fault

---

Option C — Accept SNAT and map logs back (if you cannot change routing/DNS)

If you cannot change DNS or the server routing, you may be forced to accept SNAT (server will see gateway IP). In that case:

• Keep the hairpin SNAT for connectivity.

• Correlate logs on the firewall (or use X-Forwarded-For at the webserver/proxy) to recover original client IPs:

  • Put a reverse proxy (or web server) that inserts X-Forwarded-For with original client IP (the proxy sits in front of the webserver and is not SNATed).

  • Have the gateway forward actual client IPs via an HTTP header (if you can place a proxy or LB).

  • On Check Point, you can also log NAT translations and correlate firewall logs to server logs to map gateway IP connections back to original clients.

Tradeoffs:

• Adds components (proxy, LB) or more log correlation work.

• Not as clean as preserving IP in the web server access logs.

Community notes call this the typical "disadvantage" of hairpin NAT — connectivity works but server loses the original source IP. Check Point CheckMates+1

---

Example SmartConsole manual NAT rule (illustrative)

(You don’t need to match labels exactly, just the idea)

Manual NAT rule (placed above automatic NAT rules):

• Original Source: VLANs_Networks (e.g. 10.10.0.0/16, 10.20.0.0/16, …)

• Original Destination: Server_Public_IP (object)

• Service: HTTP/HTTPS

• Translated Destination: Server_Private_IP

• Translated Source: Original ← do not hide/SNAT

Then verify:

• fw ctl zdebug drop / logs for NAT if you have connection problems.

• Ensure server gateway = firewall (or static routes for all VLANs via firewall).

---

Short checklist you can run through right now

1. Create manual NAT rule as shown (Translated Source = Original).

2. Ensure server routes to all client VLANs via the firewall (server default gateway is firewall is easiest).

3. Install policy and test from one VLAN.

4. If server still sees gateway IP, check server routing (it is replying directly to client). If replies bypass the firewall you’ll need to add routes or use split-horizon DNS.

5. If you cannot change routes/DNS, consider reverse proxy + X-Forwarded-For or server-side log correlation.

[PhoneBoy]

The hairpin NAT rules are necessary to force the traffic through the gateway so NAT can be performed on all packets in the connection.
Unless the VLANs terminate directly on the firewall AND the firewall is the default route for all affected VLANs, I don't see how you can achieve this.