Problem - firewall rule with virtual IP to internal FQDN

[jcrower]

Fortigate 81F
FortiOS 7.0.16

Hi all, I'll see if I can explain this clearly.

We have an external DNS A record webserver.com that points to one of our public IP addresses 1.2.3.4.

On the Fortigate we have a Virtual IP that points to an FQDN internal DNS A record webserver.internal. webserver.internal has a private IP address 192.168.1.1.

On the Fortigate we have a firewall rule that permits access to the Virtual IP on port 443.

Internally we have a Windows failover cluster service that can change the IP address of webserver.internal to another private IP on a different subnet 192.168.2.1.

Issue: when webserver.internal is pointing to 192.168.1.1 everything works fine. When webserver.internal is pointing to 192.168.2.1, there is no longer any external access.  Internal access continues to work fine.

After the IP address of webserver.internal changes, this change is successfully reflected on the Fortigate. On the Fortigate if I go to Addresses, the webserver.internal record successfully resolves to the new IP 192.168.2.1 (it has a 5 minute ttl). The Fortigate can successfully ping and traceroute to the new IP.

This sounds like it might be an internal routing issue, but from the moment the IP for webserver.internal changes to 192.168.2.1, there are no longer any hits recorded on that Fortigate firewall rule, the only reference to that virtual IP is in the the implicit deny, and that is for legitimate denies (i.e. attempts other than HTTPS). The external DNS records are not changed at all.  Once the IP for webserver.internal changes back to 192.168.1.1, everything works fine again.

Has anyone encountered this issue before and has hopefully resolved it?

thanks

j

[dingjerry_FTNT]

Hi @jcrower ,

I suspect you do not have a routing entry for 192.168.2.1 on FGT.

Please share the routing table (get router info routing table all), the settings of the firewall policy with the VIP, the destination interface settings, and the VIP settings.

[dingjerry_FTNT]

And if there is no source NAT enabled on the firewall policy in this issue, please run debug flow commands which will tell you why the traffic is dropped:

diag debug flow show iprope enable

diag debug flow filter addr x.x.x.x   //  This is your client's public IP, go to https://www.whatismyip.com/ to get the public IP

diag debug flow trace start 20

diag debug enable

Then reproduce the issue to collect the outputs.

[jcrower]

Thanks for the reply @dingjerry_FTNT 

The routing table does have an entry for the subnet in question (via OSPF).  The Fortigate can successfully ping and run a traceroute to the IP.  Even if the Fortigate couldn't resolve the FQDN, surely it would still register a hit on that firewall rule?

[dingjerry_FTNT]

"Even if the Fortigate couldn't resolve the FQDN, surely it would still register a hit on that firewall rule?"

No, not really. We need to run the debug flow commands first.