Support Forum
The Forums are a place to find answers on a range of Fortinet products from peers and product experts.
ForgetItNet
Contributor

Ping reply but no sent Ping and also destination unreachable

Hi all,

 

Got 2 Fortigate 100E's at 2 branches, these run BGP and connect in a hub and spoke setup to our head office with a site to site VPN. We have 2 sub-interfaces on each of the branch Fortigates (v7) for our VOIP phones. The setup is this, siteA have main LAN of 192.168.1.20 and sub interface for VOIP of 192.168.2.20 and there is a phone server on there on IP of 192.168.2.215. siteB has main LAN of 192.168.70.20 and sub interface for voip of 192.168.159.20 and has a phone server on there on 192.168.159.6. 

I can ping successfully from the Fortigates from 192.168.2.20 to 192.168.159.6 and also from 192.168.2.215 to 192.168.159.20 and from 192.168.159.20 to 192.168.2.20 and 192.168.2.215 so the sub interfaces can see the devices on the sub-interfaces both ways however if i do a source ping from the phone servers on 192.168.2.215 and 192.168.159.6 to each other then i get no response.

I've ran a packet sniffer on both sides and weirdly enough the one when pinging from siteA and pinging from 192.168.2.215 to 192.168.159.6 i get an Echo Ping Reply frim 192.168.159.6 (source) to 192.168.2.215 (dest) but then a destination unreachable from 192.168.2.215 (source) to 192.168.159.6 (dest). If i then run it from siteB i ONLY get an Echo Ping Reply form 192.168.2.215 (source) to 192.168.159.6 (dest) but no Echo request ?

I've tried putting in a firewall rule on both sides to allow ICMP through from VOIP to the VPN HUB but it doesn't make any difference.

Anyone see what i'm doing wrong here or missing ?

Thanks (and i'm hoping i've written that down correctly :) )

11 REPLIES 11
AlexC-FTNT
Staff
Staff

=====Site A--------------VPN--------------Site B===

192.168.1.20/24--------------------------192.168.70.20/24

192.168.2.20/24 -------------------------192.168.159.20/24

----SIP 192.168.2.215-------------------   ----SIP 192.168.159.6

 

The ping request/replies that you describe are not really clear, or not plausible.

You can't have a reply without a request, unless the traffic flows asymmetrically.

Use "any" filter for interface, and "host" or "net" instead of "src / dst ". For example:

diag sniffer packet any "net 192.168.159.0/24 and icmp" 4 0

https://community.fortinet.com/t5/FortiGate/Troubleshooting-Tip-Using-the-FortiOS-built-in-packet-sn...

 

ping from .159.6 > .2.215

  >> do you see the request and reply on site A FortiGate? 

ping from .2.215 > .159.6

  >> do you see the request and reply on site B FortiGate?


- Toss a 'Like' to your fixxer, oh Valley of Plenty! and chose the solution, too00oo -
AlexC-FTNT

not lastly, check the IPSEC selectors to make sure they match the whole subnet and not /32 addresses


- Toss a 'Like' to your fixxer, oh Valley of Plenty! and chose the solution, too00oo -
ForgetItNet
Contributor

Thanks,

 

So, doing a ping with just ICMP as opposed to anything for specific addresses i get a request and reply both ways on either side so:

 

ping from .159.6 > .2.215

  >> do you see the request and reply on site A FortiGate? - Yes

ping from .2.215 > .159.6

  >> do you see the request and reply on site B FortiGate? - Yes

 

Where do i see the IPSEC selectors as i didn't set these up but i've gone into the IPsec Tunnels settings but can only see Phase2 selectors which are set to 0.0.0.0/0.0.0.0 ? I can see IP ranges on the SSL-VPN settings but suspect these are for the dial in VPN users ?

 

 

ForgetItNet
Contributor

lol......i've removed an older firewall rule that WAS there (i suspect someone added this a while ago for some reason) so i could start from scratch and it's now working.....Sorry for the wasted time but still not sure why i got different packet results using ICMP with any source/dest as opposed to ANY with specific source/dest ?

AlexC-FTNT

Glad to hear it works now. 
The results for the capture differ, because a message exchange has an IP in both roles:

request: source.IP: 1.1.1.1 >> destination.IP: 2.2.2.2

reply: source.IP: 2.2.2.2 >>> destination.IP: 1.1.1.1
If you filter by "src 1.1.1.1" you will only see the first packet (request).


- Toss a 'Like' to your fixxer, oh Valley of Plenty! and chose the solution, too00oo -
ForgetItNet
Contributor

mmm...spoke too soon. It's now stopped again and i can't ping one to the other. I've ran another trace and on both sides pinging as the phone server as the source to the other phone server (so 192.168.2.215-192.168.159.6 and vice versa) i'm getting a ping reply but the request is showing as Destination unreachable (protocol unreachable) on both sides which makes no sense as it would have to have sent the request for it to receive the reply ?

ForgetItNet
Contributor

Just seems a bit odd that i removed the old policy and it worked but now doesn't so wondering if that was a red herring and there's something like a rogue MAC address taking the same IP but i can't find anything on the network

AlexC-FTNT
Staff
Staff

when you use source-ip for simulating traffic on the FortiGate, the IP must be defined on one of the FG interfaces. Any other IP will not have desired output. Try to capture traffic generated from these machines, even if not ICMP


- Toss a 'Like' to your fixxer, oh Valley of Plenty! and chose the solution, too00oo -
ForgetItNet
Contributor

Right so that makes a bit of sense now....so i can get onto one of the phone servers (192.168.2.215) but not on the other as there's no GUI on that model so i've pinged 192.168.159.6 from 192.168.2.215 and the packet trace picks up nothing at all....no request and no reply ? I did however choose the interface as the SIP interface but that would've picked it up if there WAS icmp traffic going through it wouldn't it ?

Labels
Top Kudoed Authors