Can' t ping despite policy allowing all access

[kkeane]

I' d appreciate some help troubleshooting a thorny issue where I can' t ping a server that is located behind a firewall, despite a policy that I believe would allow all access. The short of it is that I have a network with device identification, where identified devices are allowed (and able to) connect to the outside world. But I also want to allow inbound connections to the same network. This is what I can' t seem to get working. The long version: this takes place across a VPN between two Fortigates. Both Fortigates have multiple networks behind them, but I' ll just diagram the relevant ones here: Net1 ------> FG1 ------ IPSec VPN ------> FG2 ----------> Net2 ----------> Net3 Net1: 192.168.1.0/24 - gateway is 192.168.1.1 Net2: 192.168.17.0/28 - gateway is 192.168.17.1, with a device identification policy on this interface. Net3: 192.168.17.128/25 - gateway is 192.168.17.129, no device identification policy on this interface. I can ping from Net1 to servers in Net3, and also to 192.168.17.1 (the gateway address of Net2), but not to 192.168.17.5 on Net2. 192.168.17.5 can connect outbound, so I am reasonably sure this is not a routing problem. I am wondering if this might be because on Net2, I am using a device identity policy, even though that policy is further down in the list. I created the following policies on FG2 (in this order): Src Interface: VPN Src Address: all Dst Interface: Net2 Dst Address: all Services: all Action: allow (the counter in this rule, and the fortigate logs, shows that my pings are accepted, so it is probably the echo response that is somehow blocked). ... (unrelated policies for other interfaces) (Device Identity Policy for devices on Net2) Src Interface: Net2 Src Address: all Device: authorized servers (includes the one I am trying to ping) Destination address: all Services: all Action: allow (there are additional authentication rules, but the first one is already an allow-all rule).

[rwpatterson]

You do realize that NET3 is a subset of NET2... Also with identity based policies, any matching from-to pairs below will never get hit.

[kkeane]

Ah, thank you! I suspected as much. So basically, any network that has identity-based policies can' t also have regular policies? Ultimately, the question then becomes: how does one handle inbound connections with identity-based policies? Ultimately, the goal is to be able to set up an RDP session to one of the identified devices through the Fortigate.

[emnoc]

what do you mean a subset? net2 and net3 are 2 unique subnets within the 192.168.17.0/24 block. Op, what does you diag debug flow for icmp packet generate at the left or right gateways?

[rwpatterson]

You are right... I need to get to bed... All 4 of my eyes saw /24...

[kkeane]

emnoc, thank you so much for pointing me to the debug flow command! That was exactly what I needed. It showed me that the ICMP packets traveled through the firewall and left on the correct interface, but the target computer never sent a response. Armed with that knowledge, I found out that somebody had misconfigured the Windows firewall on the target computer. Wasn' t a Fortigate issue at all! Thanks for your help!

[emnoc]

:) I had to go get my extra 2 eyes to be sure that I didn' t missed read anything.

[emnoc]

I can' t speak enough for diag debug flow. It validates that packets are being sent, and actually matching against a firewall policy-id #. http://socpuppet.blogspot.com/2013/03/flow-diagnostic-fortigate.html