New Member

Question

fortigate virtual ip cant access from outside

Forum|Forum|6 months ago
November 25, 2025
16 replies
3657 views

I have replaced the current firewall an old 50E with a new 60F
Sadly we could not use the config file from the old one.

1. I have setup VirtualsIP for our meters(we have meters that collects info for our building)
2. And then i did a virtual IP Group, with all the meters
3. Then i setup Firewall policy

The issue i have is that i cannot access the meters when i am on another network(over internet).

Here is how i have setup the firewall, have i forgotten something. Must say i am not used to work with firewalls at all.

Toshi_Esumi

SuperUser

The VIP is for accessing from the Internet to wan1 interface. If the "another network" you're coming from is inside of this 60F (not from the internet), you need to have a hairpin NAT set up explained below:
https://community.fortinet.com/t5/FortiGate/Technical-Tip-Configuring-Hairpin-NAT-VIP/ta-p/195448

Toshi

ZenhusenAuthor

New Member

We are using VIP for accessing the meters via Internet, but cant access them over internet. So when i said another network i meant internet, i will update the original question.

I can access the VIP when i am on the same network as the Firewall, and i am on that network outside the firewall
So i use the external ip adress then i can access it. But if i use another network/Internet I canot access it

Toshi_Esumi

SuperUser

Does sniffer show your access goes out to the interface where the meters are on with the correct port 80? That's the first thing to check.
Then if it's not going out, you probably need to run flow debug to see where it's going or why it's dropped.
https://docs.fortinet.com/document/fortigate/7.6.4/administration-guide/54688/debugging-the-packet-flow

Toshi

johnlloyd_13

Explorer III

hi,

try to disable/toggle the 'NAT' setting in the FW policy.

VIP will perform the inbound and outbound internet access for the VIP group.

Toshi_Esumi

SuperUser

If the default route at the destination is not coming back to the FGT, yes, changing the the source IP to the FGT itself with NAT is necessary. But if that's not the case, having NAT or no-NAT won't affect the incoming packets to reach the destination. Only returning packets direction might change.

At this moment, you don't know if it's going out toward the internal devices, which you need to confirm first.

Toshi

ede_pfau

SuperUser

IMHO the policy does not allow this traffic.

It needs to allow HTTP (port 80) and your custom service (tcp/10020). Please give it a try.

If unsuccessful, run a 'diag debug flow' to see what happens. Post it here for interpretation.

funkylicious

SuperUser

like @ede_pfau mentioned, if in the VIP you are using custom port forwarding then in the firewall rule I would set in the services option either ALL ( since you are using PubPort>PrivPort, 1:1 ) or those specific ports ( PubPort ) from the VIP in the services.

"jack of all trades, master of none"

ZenhusenAuthor

New Member

Chnaged the service option to all and no chnage cant access from intenet

GauravPandya

Explorer

In the policy, disable NAT and put VIP object e.g "Elvaco Nr 1"in the destination field. Try to access from internet.

yderek

Staff

@Zenhusen Try to run the flow debug while you connecting from outsite

CLI1 :

==================================================

diagnose sniffer packet any "host x.x.x.x && host y.y.y.y && port zzz" 4 0 l

Replcae x.x.x.x with your external computer public IP , y.y.y.y will be your FG WAN IP configured in VIP, zzz will be the port number of service

attempt to access the VIP from Internet and let debug run

To stop this debug using ctrl+c

==================================================

CLI2:

diagnose debug reset

diagnose debug flow filter saddr <your external source IP from computer trying to access>

diagnose debug flow filter daddr < your vip external IP configure on FG>

diagnose debug flow show function-name enable

diagnose debug flow trace start 2000

diagnose debug enable

==================================================

attempt to access the VIP from Internet and let debug run , try to access from internet couple of time

==================================================

To stop the debug using

==================================================

dia de dis

dia de reset

==================================================

Upload CLI 1 and 2 in this topic after

ZenhusenAuthor

New Member

I tried the above but got nothing from cli afte i did the above

ZenhusenAuthor

New Member

Tried to do a
execute ping svd.se
Returned hosy unknown

Wouldnt that indicate that the firewall is not connected to intenet:

My ISP said that it was online

Here is some other CLI i did

FortiGate-60F # diagnose sniffer packet any "host 212.100.125.136 && host 192.168.1.27 && port 10027" 4 0 l
interfaces=[any]
filters=[host 212.100.125.136 && host 192.168.1.27 && port 10027]

Connection lost. Press Enter to start a new session.

FortiGate-60F # diagnose sys session filter clear

FortiGate-60F # diagnose sys session filter dport 10027

FortiGate-60F # diagnose sys session filter dst 212.100.125.136

FortiGate-60F # diagnose sys session filter src 192.168.1.27

FortiGate-60F # diagnose sys session list
total session 0

FortiGate-60F # exec ping 212.100.125.1
PING 212.100.125.1 (212.100.125.1): 56 data bytes

--- 212.100.125.1 ping statistics ---
5 packets transmitted, 0 packets received, 100% packet loss

FortiGate-60F # get system arp
Address Age(min) Hardware Addr Interface
192.168.1.2 0 58:11:22:e8:7a:15 internal
212.100.125.1 167 74:83:ef:71:f8:4b wan1

FortiGate-60F #

FortiGate-60F # diagnose sniffer packet internal " arp" 4 0 1
interfaces=[internal]
filters=[ arp]
0.114278 internal -- arp who-has 172.16.0.1 tell 172.16.0.43
0.280906 internal -- arp who-has 172.16.0.1 tell 172.16.0.42
0.757845 internal -- arp who-has 192.168.1.20 (ff:ff:ff:ff:ff:ff) tell 192.168.1.20
1.114510 internal -- arp who-has 172.16.0.1 tell 172.16.0.43
1.175376 internal -- arp who-has 192.168.1.99 tell 192.168.1.25
1.175408 internal -- arp reply 192.168.1.99 is-at ac:71:2e:da:d4:57
1.758679 internal -- arp who-has 192.168.1.20 (ff:ff:ff:ff:ff:ff) tell 192.168.1.20
2.114272 internal -- arp who-has 172.16.0.1 tell 172.16.0.43
3.114296 internal -- arp who-has 172.16.0.1 tell 172.16.0.43
4.093850 internal -- arp who-has 192.168.1.21 (ff:ff:ff:ff:ff:ff) tell 192.168.1.21
4.114594 internal -- arp who-has 172.16.0.1 tell 172.16.0.43
5.113001 internal -- arp who-has 192.168.1.21 (ff:ff:ff:ff:ff:ff) tell 192.168.1.21
5.114301 internal -- arp who-has 172.16.0.1 tell 172.16.0.43
5.217058 internal -- arp who-has 192.168.1.99 tell 192.168.1.20
5.217087 internal -- arp reply 192.168.1.99 is-at ac:71:2e:da:d4:57
6.114325 internal -- arp who-has 172.16.0.1 tell 172.16.0.43
7.578760 internal -- arp who-has 192.168.1.99 tell 192.168.1.21
7.578791 internal -- arp reply 192.168.1.99 is-at ac:71:2e:da:d4:57
23.017858 internal -- arp who-has 192.168.1.27 (ff:ff:ff:ff:ff:ff) tell 192.168.1.27
24.018775 internal -- arp who-has 192.168.1.27 (ff:ff:ff:ff:ff:ff) tell 192.168.1.27
24.107735 internal -- arp who-has 172.16.0.1 tell 172.16.0.44
25.106749 internal -- arp who-has 172.16.0.1 tell 172.16.0.44
26.106734 internal -- arp who-has 172.16.0.1 tell 172.16.0.44
26.603363 internal -- arp who-has 192.168.1.99 tell 192.168.1.27
26.603391 internal -- arp reply 192.168.1.99 is-at ac:71:2e:da:d4:57
27.106982 internal -- arp who-has 172.16.0.1 tell 172.16.0.44
28.106725 internal -- arp who-has 172.16.0.1 tell 172.16.0.44
29.106729 internal -- arp who-has 172.16.0.1 tell 172.16.0.44
30.107032 internal -- arp who-has 172.16.0.1 tell 172.16.0.44
31.106750 internal -- arp who-has 172.16.0.1 tell 172.16.0.44
32.106738 internal -- arp who-has 172.16.0.1 tell 172.16.0.44
44.211009 internal -- arp who-has 172.16.0.1 tell 172.16.0.41
45.209975 internal -- arp who-has 172.16.0.1 tell 172.16.0.41
46.210024 internal -- arp who-has 172.16.0.1 tell 172.16.0.41
47.210267 internal -- arp who-has 172.16.0.1 tell 172.16.0.41
48.210025 internal -- arp who-has 172.16.0.1 tell 172.16.0.41
49.210027 internal -- arp who-has 172.16.0.1 tell 172.16.0.41
50.210343 internal -- arp who-has 172.16.0.1 tell 172.16.0.41
51.210084 internal -- arp who-has 172.16.0.1 tell 172.16.0.41
52.210069 internal -- arp who-has 172.16.0.1 tell 172.16.0.41
52.282461 internal -- arp who-has 172.16.0.1 tell 172.16.0.42
53.281339 internal -- arp who-has 172.16.0.1 tell 172.16.0.42
54.281343 internal -- arp who-has 172.16.0.1 tell 172.16.0.42
55.281570 internal -- arp who-has 172.16.0.1 tell 172.16.0.42
56.281336 internal -- arp who-has 172.16.0.1 tell 172.16.0.42
57.281373 internal -- arp who-has 172.16.0.1 tell 172.16.0.42
58.117188 internal -- arp who-has 172.16.0.1 tell 172.16.0.43
58.281626 internal -- arp who-has 172.16.0.1 tell 172.16.0.42
59.114937 internal -- arp who-has 172.16.0.1 tell 172.16.0.43
59.281367 internal -- arp who-has 172.16.0.1 tell 172.16.0.42
^A60.114947 internal -- arp who-has 172.16.0.1 tell 172.16.0.43
60.281360 internal -- arp who-has 172.16.0.1 tell 172.16.0.42
61.115164 internal -- arp who-has 172.16.0.1 tell 172.16.0.43
62.114931 internal -- arp who-has 172.16.0.1 tell 172.16.0.43
63.114962 internal -- arp who-has 172.16.0.1 tell 172.16.0.43
64.115242 internal -- arp who-has 172.16.0.1 tell 172.16.0.43
65.114960 internal -- arp who-has 172.16.0.1 tell 172.16.0.43
66.114967 internal -- arp who-has 172.16.0.1 tell 172.16.0.43
84.107833 internal -- arp who-has 172.16.0.1 tell 172.16.0.44
85.106831 internal -- arp who-has 172.16.0.1 tell 172.16.0.44
86.106840 internal -- arp who-has 172.16.0.1 tell 172.16.0.44
87.107064 internal -- arp who-has 172.16.0.1 tell 172.16.0.44
88.106802 internal -- arp who-has 172.16.0.1 tell 172.16.0.44
89.106810 internal -- arp who-has 172.16.0.1 tell 172.16.0.44
90.107093 internal -- arp who-has 172.16.0.1 tell 172.16.0.44
91.106812 internal -- arp who-has 172.16.0.1 tell 172.16.0.44
92.106836 internal -- arp who-has 172.16.0.1 tell 172.16.0.44
104.211729 internal -- arp who-has 172.16.0.1 tell 172.16.0.41
105.210745 internal -- arp who-has 172.16.0.1 tell 172.16.0.41
106.210765 internal -- arp who-has 172.16.0.1 tell 172.16.0.41
107.210994 internal -- arp who-has 172.16.0.1 tell 172.16.0.41
108.210769 internal -- arp who-has 172.16.0.1 tell 172.16.0.41
109.210794 internal -- arp who-has 172.16.0.1 tell 172.16.0.41
110.211088 internal -- arp who-has 172.16.0.1 tell 172.16.0.41
111.210828 internal -- arp who-has 172.16.0.1 tell 172.16.0.41
112.210812 internal -- arp who-has 172.16.0.1 tell 172.16.0.41
112.282816 internal -- arp who-has 172.16.0.1 tell 172.16.0.42
113.281810 internal -- arp who-has 172.16.0.1 tell 172.16.0.42
114.281826 internal -- arp who-has 172.16.0.1 tell 172.16.0.42
115.282066 internal -- arp who-has 172.16.0.1 tell 172.16.0.42
116.281810 internal -- arp who-has 172.16.0.1 tell 172.16.0.42
117.281822 internal -- arp who-has 172.16.0.1 tell 172.16.0.42
118.116498 internal -- arp who-has 172.16.0.1 tell 172.16.0.43
118.282097 internal -- arp who-has 172.16.0.1 tell 172.16.0.42
119.115505 internal -- arp who-has 172.16.0.1 tell 172.16.0.43
119.281831 internal -- arp who-has 172.16.0.1 tell 172.16.0.42
120.115546 internal -- arp who-has 172.16.0.1 tell 172.16.0.43
120.281836 internal -- arp who-has 172.16.0.1 tell 172.16.0.42
121.115782 internal -- arp who-has 172.16.0.1 tell 172.16.0.43
122.115541 internal -- arp who-has 172.16.0.1 tell 172.16.0.43
123.115555 internal -- arp who-has 172.16.0.1 tell 172.16.0.43
124.115858 internal -- arp who-has 172.16.0.1 tell 172.16.0.43
125.115575 internal -- arp who-has 172.16.0.1 tell 172.16.0.43
126.115575 internal -- arp who-has 172.16.0.1 tell 172.16.0.43
144.107906 internal -- arp who-has 172.16.0.1 tell 172.16.0.44
145.106942 internal -- arp who-has 172.16.0.1 tell 172.16.0.44
146.106926 internal -- arp who-has 172.16.0.1 tell 172.16.0.44
147.107171 internal -- arp who-has 172.16.0.1 tell 172.16.0.44

ede_pfau

SuperUser

You cannot use 'ping' to test a port-forwarding VIP. ICMP is a portless protocol.

Which host is 172.16.0.1? There is no connectivity in the subnet.

Do you use VLANs? If so, inbound and outbound traffic to/from a FGT on a VLAN interface is always tagged.

philtrim

Explorer

Can you open Powershell window for the “other network” and run

tnc wanip -p (port#)

ZenhusenAuthor

New Member

did not work

Skärmbild 2025-12-03 143337.png

sw2090

SuperUser

The Fortigate itself has a way to find your wan ip:

on cli do "diag sys waninfo ipfy <interface> "

Besides that:

I ca give you an example that we use here:

We have some mailserver behind a fortigate that has to be reachable from the internet with some services. One is IMAPS.

So I have a policy:

name: WAN_to_imaps

Incoming interface: wan1

outoing iface: lan

Source Address: all

Destination: VIP-imaps

and then the VIP "VIP-imaps" has:

Interface: wan1

Network type: static NAT

External IP: the FGTs WAN iP on wan1

Mapped ip4v Address: internal ip of the server

Portforwarding is enabled

And its set to forward 993/TCP to 993/TCP

Works fine here...

ZenhusenAuthor

New Member

tried

FortiGate-60F # diagnose sys waninfo ipify wan1
Try to get my public IP through https://api.ipify.org with src_ip=0.0.0.0 device=wan1 vfid=0(root) ...

Failed to get my public IP, ret=-1 src_ip=0.0.0.0 device=wan1 vfid=0(root)
Command fail. Return code 5

ezhupa

Staff

Can you run a debug flow while trying to reproduce the issue or generating traffic towards the particular resource?
This way we can check if the DNAT is happening as expected, or if there is any problem with the packet forwarding.
It might be that the policy is not matching at all because the services on the policy are only HTTP and HTTPS and the ext port on one of the VIPs shown is 10020. Try setting services to ALL on the policy as a test, and try to connect again.