NAT webserver private ip address to a purchase public IP address issue

Hi Rayha

Your setup should work.

I'd check if really the public IP 12.x is mine.

To check this you can for example set it as secondary WAN IP and the try ping it from outside.

hm in this setup you might need to portforward twice.

ISP Router has to forward 80/443 to your FGT and then the FGT needs a vip to forward those to your webserver. And this has to be destination in the corresponding policy.

Hi @rayha 

19.nn.nn.nn is not a private ip!!

Private IP's is:
10.0.0.0/8
172.16.0.0-172.32.255.255 /20
192.168.0.0/16

You can make it work with the 19.nnn.nnn.nnn, but you WILL face problems at some point!

I would highly recommend you change your internal IP's to 10.x.x.x.

yes ISP Might have confugured correctly. Noone said they did wrong. It's not about misconfiguration it's about extending/changing configuration.

Setting the ISP Router Bridge mode would male things easier but would also expose your FGT to the internet directly. So one has to be careful about what is open on that wan interface then.

The advantage would be that you only would ned to vip-portforward on the fgt in this case.

What does your logging say?
Log & Report: Forward Traffic:

And also: In Policy & Objects: Firewall Policy:
do a Policy Lookup and try to see what policy you hit, when you specify the interfaces and destination port.

Here, all our WAN is handled via SD-WAN interfaces, as we have failover lines, so our FW rules have the SD-WAN interface is the Incoming interface

Hi @rayha,

To add more info, you can do sniffer on FortiGate and try to generate traffic to confirm if ISP router forward traffic correctly.

Hi @rayha,

Are you able to access your webserver using 12.xxx.xxx.218 on a web browser over the internet? Are you able to ping the webserver locally? You can run the following debug flow to see if the traffic reaches the FortiGate or not. Please replace x.x.x.x with the public IP of the client computer which you use to ping 12.xxx.xxx.218.

di deb disable
di deb res
diagnose debug flow filter clear
di deb flow filter proto 1
di deb flow filter addr x.x.x.x
diagnose debug flow show function-name enable
di deb flow show iprope en
diagnose debug console timestamp enable
diagnose debug flow trace start 500
diagnose debug enable

Run 'di deb dis' to disable the debug. 

Regards, 

I haven't read through all posts in this thread. But I sense something that could be problematic in your diagram.
Does the switch that has 19.xxx.xxx.254 happen to be a L3 switch/router and the default GW for the web server? If so, you can ping the server from the FGT no problem because they're in the same subnet on the same broadcast domain/VLAN, but anything outside like Internet might not be able to get replies back because the returning packets come though the switch(19.xxx.xxx.254) not directly from the server (19.xxx.xxx.117) and the FGT might drop them.

If that's the case, to test it, try enabling NAT/SNAT on the out-to-in VIP policy to bypass the switch.

Toshi

@rayha, now I remember, I've already seen a similar issue.

When your ISP "mentioned cannot ping this purchased Public static IP address", in fact there is a type of IP address service that is typically provided for client applications only and can't used for server publication purpose.

You should double check this with your ISP. If this is the case then you have to purchase the right type of public IP service.