Forti SSL VPN Wrong Public IP

[cvn-b]

I am running a Fortigate 100F with a SSL VPN set up on the wan port and using Forti DynDNS service to keep my public IP which is dynamic synced with my VPN hostname. It seems that the FG is seeing a different public IP as what it is really receiving from the ISP.

As an example, it shows a range of 100.72.63.x as my public IP, but when looking this up, it is 102.65.x.x.

When running diagnose sys waninfo in console, it does show the same 102.65.x.x IP address but in the interface setup, the SSL VPN settings etc it all shows 100.72.63 range.

I am running version 7.4.0

Any help would be appreciated.

[pminarik]

In the CLI (config system ddns), what is the option use-public-ip set to?
Expected behaviour:

disable = use the current IP of the chosen "WAN" interface directly (this should be the default value)

enable = use the presumed public IP obtained by polling a public API (ipify; intended for use when the FortiGate is behind NAT and the public IP doesn't belong directly to any of its interfaces)

[cvn-b]

Thank you for the quick response; Here is my current configuration:

config system ddns
edit 1
set ddns-server FortiGuardDDNS
set ddns-domain "x.fortiddns.com"
set use-public-ip enable
set monitor-interface "wan1"
next
end

Even on disabled it still doens't show the correct public ip on the WAN Interface

[pminarik]

If you are sure that the FortiGate itself is directly assigned a public IP address, then you absolutely should use set use-public-ip disable. How long it will take to update that IP is another question, which I don't know the answer to. :)

Let's keep in mind that DNS records can potentially take some time to propagate around the world.

However, be careful and confirm that it is truly a publicly routable IP. It looks to be suspiciously close (could realistically be misread/mistyped) to the CGNAT range 100.64.0.0/10, which isn't publicly routable.

[cvn-b]

I think you are right; I am establishing the WAN connection using PPPoE with credentials. In the UI, it is showing me that the WAN IP is not routable:

This interface has a private IP address (100.72.39.x) which may not be publicly accessible. Everything on my LAN is accessing the internet fine not sure why this is being misrepresented in the UI?

[pminarik]

If I'm not mistaken, FortiOS uses https://api.ipify.org/ to discover its public IP. Can you check what results that gives you?

You can try it from a browser from a device in the FortiGate's LAN. You can also check it in the FortiGate's CLI: diag sys waninfo ipify

Anyway, do you have any sort of deal with the ISP to make your FortiGate reachable from the public internet? CGNAT presence usually prevents incoming traffic, at least without the ISP explicitly setting it up.

There's also a chance that both the ISP set up a specific DNAT/VIP for your FortiGate to be reachable via IP x.x.x.x while traffic outgoing from the FortiGate will end up using IP y.y.y.y, or more IPs. Nothing technically wrong with that.

[cvn-b]

Thanks @pminarik; I don't have a deal with my ISP but the VPN worked when my WAN IP was shown correctly by the interface a few days ago. I tried rebooting the appliance and setting up the wan PPPoE connection again, still nothing.

When I run diag sys wanfino ipify in the CLI I get the following result:

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

Which is really strange as the internet on my devices on the LAN is working with no issues.

[pminarik]

> I don't have a deal with my ISP but the VPN worked when my WAN IP was shown correctly by the interface a few days ago

This I suspect you'll need to discuss with the ISP. As noted, I personally would have no expectation at all of being able to reach my FortiGate if it were behind CGNAT and there was no further documentation (from ISP) explicitly stating that it should be possible.

With regards to the waninfo command, maybe the FortiGate has trouble reaching the API server? You can resolve the name (api.ipify.org) and then run a packet capture/sniffer to check what the communication looks like. (correct interface? correct source-ip? TCP handshake finished? etc.)