0

I'm currently in the process of setting up a new Fortigate Firewall and have run into an issue while configuring DNAT. From what I understand, this is done through Virtual IPs in Fortigate. My goal is to have the NAT apply only when the target is accessed over HTTP; otherwise, the target should be accessible normally over all other ports as before. To achieve this, I've created a Virtual IP where I've specified the "External IP address" as the target that clients are trying to access, and for the "Map to IPv4 address," I've indicated the actual destination where clients will end up for HTTP access. I've enabled Optional Filters and specified HTTP under Services. However, even before I could get to setting up the firewall rules, pinging the host was already not working, even though it should still function and is already allowed. In the logs, all these packets end up being dropped by the default rule with the destination interface as root. I also added the appropriate firewall rule with the destination set to the Virtual IP object, but unfortunately, that didn't fix it. Can someone help me figure out how to resolve this so that only HTTP traffic is NATed, and not all traffic? If you need any more information, please feel free to ask.

1
  • Has any answer solved your question? Then please accept it or your question will keep popping up here forever. Please also consider voting for useful answers.
    – Zac67
    Mar 28 at 19:21

1 Answer 1

0

Destination NAT is used and required to translate connects from a client with a public IP address to a destination with a private IP address. Each forwarded port is used by a specific application protocol like HTTP.

I've indicated the actual destination where clients will end up for HTTP access. I've enabled Optional Filters and specified HTTP under Services.

A Fortigate is a firewall with (deep) protocol inspection. What you did was add a filter criterion, so that only real HTTP traffic passes your rule and no non-HTTP attempts are allowed.

pinging the host was already not working

Ping uses ICMP echo request which is an entirely different protocol.

If you don't want to translate certain traffic (by source or destination IP, transport-layer port, etc), just don't use the virtual IP which performs the port forwarding/reverse NAT/destination NAT. Instead, use the actual destination IP and set up a rule to allow that traffic. You cannot have everything within a single rule.

8
  • First of all, thank you for the quick response. However, I believe I need to clarify a few things further. We have a server where a WPAD (Web Proxy Auto-Discovery) file is located, which clients can retrieve. Now, we want to set it up so that at our site, when someone tries to access the WPAD file from, for example, 10.1.0.10, they are redirected to 10.2.0.10 and retrieve the WPAD file from there instead. However, we still need to be able to reach 10.1.0.10 via RDP and ping to manage and maintain it. There are already allowances in our firewall rule set to access 10.1.0.10.
    – Mischa-H
    Feb 27 at 13:23
  • We only want that if someone now calls 10.1.0.10 over HTTP, they land on 10.2.0.10 via HTTP. But as soon as I create the VIP object on the Fortigate, even though I limit it to the HTTP service, ping and RDP no longer work. I understand that for HTTP because the rule does not yet exist for the new server, i.e., 10.2.0.10, but the rest shouldn't actually be NATed.
    – Mischa-H
    Feb 27 at 13:24
  • What you describe sounds like simple port forwarding but it will depend on the design of the network whether it will work (where are networks 10.1.0.0/24 and 10.20.0.0/24, for example). docs.fortinet.com/document/fortigate/7.0.0/administration-guide/… If you can't do it that way, simply put a redirect on the 10.1.0.10 server or a proxy service there and then reconfigure all systems that advertise 10.1.0.10 so they give 10.2.0.20 instead. Feb 27 at 15:00
  • @Mischa-H Please make sure we understand which addresses in your question are public, which are private and where you require translation for source? or destination addresses.
    – Zac67
    Feb 27 at 15:55
  • @Zac67 Both IP addresses are private, as already mentioned in the example here, from 10.1.0.10/24 to 10.2.0.20/24. For instance, if the client network 192.168.1.0/24 tries to access 10.1.0.10 over HTTP, it should be redirected to 10.2.0.20 via DNAT. However, if a client attempts to connect to 10.1.0.10 via RDP, this should still be possible and should not be NATed.
    – Mischa-H
    Feb 28 at 7:41

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.