|
Consider the following network, where the LAN facing interface with IP address 10.254.8.65 is trying to reach public servers.
LAN<-->(10.254.8.65) FGT (96.90.29.254)<-->WAN ---> (8.8.8.8)GoogleDNS
# execute ping-options source 10.254.8.65
# execute ping 8.8.8.8
PING 8.8.8.8 (8.8.8.8): 56 data bytes
--- 8.8.8.8 ping statistics ---
5 packets transmitted, 0 packets received, 100% packet loss
# Timeout
Connection lost.
- This is an expected behavior as the ping's that are local traffic generated from FortiGate and are also from a private IP 10.254.8.65.
- To confirm if a hosts in the LAN network is able to reach the public servers (reach internet), it is recommended to test it from one of the host itself and not from the firewall.
- For the traffic going through the firewall it will hit the firewall policy and get NATed but not for the local traffic generated from the FortiGate.
- Local traffic does not match a IPv4 firewall policy.
- Here basically its being told to firewall to generate a ping with a private IP as source out through a wan port hence it'll be dropped as no private IP address will be routed.
- Testing from the firewall itself is not ideal, at least not from a private IP as source.
- Generating traffic form a host should work and the packets can be traced to see the route.
- When tested from public IP, that is sourcing the WAN IP and pinging a public IP should work.
Note:
If one wonders, why it works when source option is not chosen?
That is because when one pings 8.8.8.8, automatically public WAN IP is used as source and hence the pings will be successful.
So this is an expected behavior and not an issue with the FortiGate.
|
