Virtual IPs don't appear to be working

[lhsit]

Hello All,

I am running 6.2.4.  I have a new Internet connection via AussieBroadBand here in Aus.  Our link is DHCP but we have two static IP addresses coming in on the same link.  The two IP Addresses are both /32 addresses.

I have created a virtual IP as per the following documentation. This is very similar to the pfSense and I have done this previously with the pfsense in a separate environment.

https://docs.fortinet.com/document/fortigate/6.0.0/cookbook/502582/creating-a-security-policy

I have also created the IPv4 policy as per the documentation.  However, it doesn't seem to work.  In the port forwarding section I forwarded ICMP and have monitored for incoming ICMP on the target machine but don't see any packets reaching the internal machine.

I am starting to wonder whether my ISP is in fact forwarding those packets to me.  It's been a long time since I've done any packet sniffing on the fortigate, I'm hoping someone can help me with the commands I need to issue in the cli on the fortigate to attempt to see those packets coming in.

Any other advice would be most welcome.

Thanks,

Chris.

ps.  moved from the routing forum. this seems more appropriate here.

[lobstercreed]

No need to do any port forwarding.  Not sure why the documentation tells you to do that unless the different applications live on different servers and share the same public IP.  Especially since you're not having it work, I would turn all port forwarding off and then just make sure your policy specifies the services (PING for example) that you want to allow inbound.

There is a place to create packet captures in the GUI depending on your platform under Network -> Packet Capture.  That's what I would use to see if your ISP is even sending you the packets.

diag debug flow is what a couple of the more active folks in here will recommend using though...so if you prefer CLI you might investigate that.  It's useful for a lot of more advanced situations.

[lhsit]

lobstercreed wrote:

No need to do any port forwarding.  Not sure why the documentation tells you to do that unless the different applications live on different servers and share the same public IP. 

<snip>

diag debug flow is what a couple of the more active folks in here will recommend using though...so if you prefer CLI you might investigate that.  It's useful for a lot of more advanced situations.

Thanks lobstercreed, I turned off the portfowarding and found an example of diag debug flow - that was a great suggestion.

Again, I can see the packets if I ping the dhcp address, but nothing if I ping the static IP address.  I am starting to wonder if the ISP is actually forwarding those packets.  That will be my next port of call.

Cheers,

Chris.

[rwpatterson]

From what I recall, ICMP will only be forwarded if port forwarding is disabled on an interface. As a test, disable port forwarding and see if the internal device does indeed receive the packets. For what it's worth, I wouldn't use that as a test. Packet sniffing on the correct protocol and destination IP would be how I would go about it.

[drmorg]

I am having a similar issue after upgrading to 6.2.4. 

Approximately 12 hours after reboot dnat stops working: our site doesn't respond, ssl-vpn does not connect etc. This happens only on primary ISP interface, i can connect to secondary (but it's really slow)'diag sniffer packet any "host {external ip} and port 443" 4 0 a' - shows only inbound packets, there is no outbound to landiagnose debug flow - show nothing at allReboot help but temporary.My gues it's a bug and i am now considering downgrade to 6.2.3.

[James_G · Accepted solution]

It’s a known bug with denial of service ‘dos’ policy, disable dos policy or downgrade are only options.

[lhsit]

I have managed to figure out how to do a packet sniffer.  I can see pings coming into the device for the DHCP ip address, but I don't see any pings coming in for the virtual IP.  I'm thinking I should be able to see those packets coming in at that port?

Cheers, Chris.

[lobstercreed]

You seem to be saying that you can and that you can't do a packet sniffer?  The GUI option I just gave you and also suggested about the CLI.  But if you're seeing the packets like you're describing then it sounds like you've already figured it out and the answer is that your ISP isn't sending them to you.