Skip to main content
HernanAraujo
HernanAraujo
New Member
February 19, 2018
Question

Problem with policies and ICMP.

  • February 19, 2018
  • 2 replies
  • 8502 views
Good day, afternoon or evenings, depending on the case, we would like you to support us with the following problem that we are having, recently we just updated the firmware of our Fortigate 200D from version 5.2.11 to 5.6.3, but for some reason that we do not know, the policies have not been applied correctly, since the L2L connections with some localities are not responding PING, that happens only with some localities not with all, we would like to know if there is any command for CLI that could validate the health of the policies in relationship to a protocol and a network in particular, in this case ICMP, since those same localities that do not respond to PING, are operational and working normally through other protocols, since we can access them via HTTP or RDP without problems ... !!!!   Best regards...!!!

2 replies

ede_pfau
SuperUser
ede_pfau
SuperUser
February 20, 2018
hi,   and welcome to the forums. I need more information about these policies. What do you mean with "L2L" connection - an IPsec VPN, L2TP, ...? Or do you use VIPs? Please post one representative policy (in text form, from CLI "conf firewall policy", edit <n>, show).
HernanAraujo
HernanAraujoAuthor
New Member
February 22, 2018
Hi.-   Thanks, ok, it's a VPN Ipsec, i made a diagnose sniffer packet over one of the networks (i share here) what i have the issue, maybe you can see something that my expertise won't permit me see.           
Connected
 
Evenpro_1 $ diagnose sniffer packet any "host 172.20.30.1"
interfaces=[any]
filters=[host 172.20.30.1]
54.284160 172.20.5.176.35697 -> 172.20.30.1.161: udp 57
58.288376 172.20.5.176.35697 -> 172.20.30.1.161: udp 57
88.128023 172.20.5.176 -> 172.20.30.1: icmp: echo request
89.128383 172.20.5.176 -> 172.20.30.1: icmp: echo request
90.128553 172.20.5.176 -> 172.20.30.1: icmp: echo request
146.539845 172.20.5.176.38701 -> 172.20.30.1.161: udp 54
150.544142 172.20.5.176.38701 -> 172.20.30.1.161: udp 54
181.735838 172.20.5.184 -> 172.20.30.1: icmp: echo request
211.085592 172.20.5.176 -> 172.20.30.1: icmp: echo request
212.086005 172.20.5.176 -> 172.20.30.1: icmp: echo request
213.086172 172.20.5.176 -> 172.20.30.1: icmp: echo request
238.666728 172.20.5.176.45814 -> 172.20.30.1.161: udp 56
242.670830 172.20.5.176.45814 -> 172.20.30.1.161: udp 56
243.354677 172.20.5.184 -> 172.20.30.1: icmp: echo request
330.796173 172.20.5.176.35502 -> 172.20.30.1.161: udp 56
333.942596 172.20.5.176 -> 172.20.30.1: icmp: echo request
334.797247 172.20.5.176.35502 -> 172.20.30.1.161: udp 56
334.942801 172.20.5.176 -> 172.20.30.1: icmp: echo request
335.943152 172.20.5.176 -> 172.20.30.1: icmp: echo request
423.286442 172.20.5.176.55479 -> 172.20.30.1.161: udp 56
427.290585 172.20.5.176.55479 -> 172.20.30.1.161: udp 56
457.547137 172.20.5.176 -> 172.20.30.1: icmp: echo request
458.547563 172.20.5.176 -> 172.20.30.1: icmp: echo request
459.547699 172.20.5.176 -> 172.20.30.1: icmp: echo request
481.114562 172.20.5.184 -> 172.20.30.1: icmp: echo request
515.397068 172.20.5.176.49510 -> 172.20.30.1.161: udp 56
519.401241 172.20.5.176.49510 -> 172.20.30.1.161: udp 56
541.539585 172.20.5.184 -> 172.20.30.1: icmp: echo request
580.926670 172.20.5.176 -> 172.20.30.1: icmp: echo request
581.926883 172.20.5.176 -> 172.20.30.1: icmp: echo request
582.927465 172.20.5.176 -> 172.20.30.1: icmp: echo request
607.518152 172.20.5.176.59883 -> 172.20.30.1.161: udp 56
611.522320 172.20.5.176.59883 -> 172.20.30.1.161: udp 56
699.697444 172.20.5.176.40193 -> 172.20.30.1.161: udp 54
703.701535 172.20.5.176.40193 -> 172.20.30.1.161: udp 54
704.265951 172.20.5.176 -> 172.20.30.1: icmp: echo request
705.266277 172.20.5.176 -> 172.20.30.1: icmp: echo request
706.268833 172.20.5.176 -> 172.20.30.1: icmp: echo request
781.135739 172.20.5.184 -> 172.20.30.1: icmp: echo request
791.815900 172.20.5.176.56173 -> 172.20.30.1.161: udp 56
795.820098 172.20.5.176.56173 -> 172.20.30.1.161: udp 56
827.611664 172.20.5.176 -> 172.20.30.1: icmp: echo request
828.611810 172.20.5.176 -> 172.20.30.1: icmp: echo request
829.612288 172.20.5.176 -> 172.20.30.1: icmp: echo request
 
45 packets received by filter
0 packets dropped by kernel
 
Evenpro_1 $
ede_pfau
SuperUser
ede_pfau
SuperUser
February 25, 2018
The sniffer output doesn't help. Try and apply a 'diag debug flow' session, once to pinging and one time to some other traffic. Are you sure the remote host will respond to ping (local firewall)? And there is no VIP involved somewhere?
rwpatterson
rwpatterson
New Member
February 26, 2018

HernanAraujo wrote:
Good day, afternoon or evenings, depending on the case, we would like you to support us with the following problem that we are having, recently we just updated the firmware of our Fortigate 200D from version 5.2.11 to 5.6.3, but for some reason that we do not know, the policies have not been applied correctly, since the L2L connections with some localities are not responding PING, that happens only with some localities not with all, we would like to know if there is any command for CLI that could validate the health of the policies in relationship to a protocol and a network in particular, in this case ICMP, since those same localities that do not respond to PING, are operational and working normally through other protocols, since we can access them via HTTP or RDP without problems ... !!!!   Best regards...!!!
Did you follow the correct upgrade path, or did you simply jump to the latest version?

Terms & ConditionsAccessibility statement