Support Forum
The Forums are a place to find answers on a range of Fortinet products from peers and product experts.
rayha
New Contributor III

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

Hi all,

    

     Really need someone advise on this issue. Below is my network setup.

Network_diagram.png

 

      I had purchased a public static IP address 12.xxx.xxx.218 from my internet provider.

      I had a web server private IP address: 19.xxx.xxx.117. 

      I need to NAT the private IP address: 19.xxx.xxx.117 to public static ip address 12.xxx.xxx.218 so that i only need to input 12.xxx.xxx.218 on a web browser over the internet to access my webserver 

      In the end, i still cannot ping 12.xxx.xxx.218 after i done some NAT configuration inside the firewall.

      Below is my firewall setup for NAT:

    

                      This is the firewall Port 13 interface

LAN1.png

 

                This is the firewall Wan1 interface

Wan1.png

 

    I had created a Virtual IP named NUC Gateway

virtual IP.png

 

I had configure a LAN to WAN for internet access

- NAT is turned on

Wan-LAN.png

 

 - I had created a Wan to LAN where i input my previous created virutal IP "NUC gateway" and selected at the      Destination field

- I do not turn on NAT

LAN-WAN.png

     Anyone experience on this setup, can advise what went wrong?

 

20 REPLIES 20
Jakob-AHHG
Contributor II

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.

Jakob Peterhänsel,
IT System Admin,
Arp-Hansen Hotrel Group A/S, Copenhagen, DK
Jakob Peterhänsel,IT System Admin,Arp-Hansen Hotrel Group A/S, Copenhagen, DK
rayha
New Contributor III

Hi Jakob,

 

       Thank for pointing out. The IP address in the diagram is for illustration purpose as i do not think much when doing this. 

 

       But you can be sure that all the private and public IP addresses are in the right order.

 

       Thanks

sw2090
Honored Contributor

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.

-- 

"It is a mistake to think you can solve any major problems just with potatoes." - Douglas Adams

-- "It is a mistake to think you can solve any major problems just with potatoes." - Douglas Adams
Jakob-AHHG
Contributor II

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

Jakob Peterhänsel,
IT System Admin,
Arp-Hansen Hotrel Group A/S, Copenhagen, DK
Jakob Peterhänsel,IT System Admin,Arp-Hansen Hotrel Group A/S, Copenhagen, DK
mle2802
Staff
Staff

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.

hbac
Staff
Staff

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, 

Toshi_Esumi
SuperUser
SuperUser

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

AEK

Hi Toshi

I think the issue is at WAN level, since Rayha has already tested to set the public IP as secondary address. See Rayha's feedback below.

 

I had tried put it as a WAN secondary IP. I cannnot ping the WAN secondary IP. According to my internet provider, they mentioned cannot ping this purchased Public static Ip address which i feel strange. So now i cannot ping, does it mean this not belong to me?

AEK
AEK
Toshi_Esumi

Ok, then there might be two problems.

 

Toshi

AEK
SuperUser
SuperUser

@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.

AEK
AEK
Labels
Top Kudoed Authors