Port forwarding vs Static NAT in Virtual IPs

[#1]

To publish our websites behind our Fortigate unit, we initially used Static NAT in our Virtual IPs (VIPs) and then created the policies to publish the site and allow only HTTP and HTTPS traffic to them. We recently had occasion to make us investigate using Port Forwarding for our VIPs. Once we changed the VIPs to be Port Forwarding, I could no longer do a tracert to the public IP of any of our websites. It would hit the LAN IP of the Fortigate and then give me " Destination Host Unreachable" . I also could not reach some of our sites internally even though an nslookup correctly identified the public IP address they were using. Without the Static NAT, it' s like the public IP addresses are not bound to the NIC of the firewall. Has anyone else seen anything like this and, if so, how did you overcome it besides the obvious - use Static NAT?

[UkWizard]

If you are using port forwarding, then the IP isnt in use, so i would expect this behaviour. If you want to ping or do any other traffic, you would need static nat. Essentially no other connections (except to ports that are setup for the port forwarding) would be allowed. Why would you want to perform a trace to your own webservers anyway ? If you really want to, why not go back to using Static Nat ?

[#3]

Why would you want to perform a trace to your own webservers anyway?

First, you need to understand the reasoning for moving from Static NAT to Port Forwarding. We have 3 separate IIS servers behind our firewall with the exact same configuration, sites, etc. (except IP addresses). This way, we can move any of our public sites to a different server by simply changing the forwarding in the firewall. This is as opposed to using clustering for true failover capability - they are still not comfortable with having us do that. Hence, our situation. That said, we have one of our public IP addresses that is used for FTP.mydomain.com and for WWW.mydomain.com. The powers that be wanted to be able to move FTP independently of WWW. Therefore, with a Static NAT, I always have to tie the WWW and FTP together and move them to another server together. Port Forwarding would allow me to do this since port 21 and port 80 could be independently assigned to separate LAN servers. This past week, we tried going to Port Forwarding instead of Static NAT. The first indication something was wrong was our users could not hit one of our websites. Before you mention internal DNS, this is a site hosted for a customer where they point their DNS entry to our IP address. I tried to do an NSLOOKUP of the domain name and it resolved the proper external IP address. When I did a trace, the last good hop was the Internal IP of the Fortigate. The next one said Destination Host Unreachable. Also, some external clients were not able to reach some of our websites. I verified this fact by trying it from my home and I was unable to reach these sites unless we went back to Static NAT. That is the reason I would try to trace to my own web sites.

[UkWizard]

I see, but you dont really want to use traceroute to test whether a PORTS open, i often use web based port testing for this, or by going to the port directly. Have a look at the http://centralops.net then click the Domain Dossier, in there you can type IP or domain names and tick the service scan. It will check whats ports are open. You cannot use tracert as the firewall would block it externally anyway (or should be configured to).

[#5]

I didn' t try the tracert from external. That was internal only. I agree that external ICMP traffic should not be allowed. Also, the tracert was not for the purpose of finding an open port. It was simply to see if my traffic to that IP was going properly from inside. My question would be this . . . if Port Forwarding does not bind the external IP to the Fortigate' s external interface, how would anyone on the Internet be able to view a website that is served from that IP address?

[UkWizard]

It doesnt bind to it as such, it just responds to arps for the other IP you are natting. But if you dont have a static nat, you cannot trace or ping it. You will only be able to connect to the ports that you have opened.

[#7]

OK, I see what you are saying and why you thought I was doing a tracert to a specific port. Why do you think external customers were unable to reach certain websites I am hosting when I was in Port Forwarding mode?

[UkWizard]

did it not work from the start, or was intermittent later ?

[#9]

It was OK at first because we still had the Static NAT setup in VIP settings - just didn' t use them in a policy. Once we deleted these static NAT VIP settings, it began to fail. Furthermore, when we originally had the static NAT, we could use the same external IP to create our Port Forwarding VIPs and they coexisted. Once I created all the Port Forwarding VIPs and removed the Static NAT ones, I couldn' t add back a Static NAT VIP if that external IP was used in a Port Forwarding VIP.

[UkWizard]

You may find that when you switched to the port forwrding, the access from internally stopped, whereas the external may have still worked. Or the rules may of needed to be changed. It is correct, you should not be able to use a static nat AND a port forwarding on the same external IP address, as these would conflict with one another.