icmp timeouts with PRB

[saitoh]

Hi all,

I hesitate to ask this because I think this is quite elementary, but I need a bit of explanation.

I am testing how policy based routing works in CP, wanting to make CP route packets to eth0 or eth2, according to what a certain packet is.

The environment as follows.

FortiGate has allow-all policy, no UTM activated.

GW1, 2 play role of cluster of ClusterXL.

Here eth1 is in trusted zone, eth0, eth2 untrusted.

Default route is set on eth0, and only HTTPS to FGT's external IP (10.11.124.1) goes to eth2 by policy based routing.

The test above was successful.

I made changes to routing policy for only ICMP to go through eth2, which failed due to timeouts.

I am not experienced enough to understand what is happening.

I believe this is quite basic networking topic, not the one of CP...

I feel sorry to ask this stupid question, but your comments would be highly appreciated.

Saitoh

[Chris_Atkinson]

What is the source & destination IP addresses of your test traffic?

(Note a limitation is that traffic originated from the gateway itself is not subject to PBR per sk167135).

[saitoh]

Hi @Chris_Atkinson ,

Thanks for your comment.

I tested ICMP routing from WindowsVM (10.31.10.1) to FortiGate external (10.11.124.1).

I configured PBR policy for CP to pick up ICMP traffic only from WindowsVM to FGT external and send it through eth2.

It goes through without any mishaps when I delete the policy of PBR, so I assume PBR matters in this occasion.

Saitoh

[Lesley]

Do you have something configured like

 static-route {...} ping {off | on}?

gateway can use ping to monitor gateways. Maybe this options influences your test with ping? 

https://sc1.checkpoint.com/documents/R81/WebAdminGuides/EN/CP_R81_Gaia_Advanced_Routing_AdminGuide/T...

[saitoh]

Hi @Lesley ,

Thanks for your comments.

I checked out monitored IPs settings in PBR, but no IP is set to be monitored.

When I deleted PBR settings ping goes successful, so some point in PBR setting matters, as you mentioned, I guess.

Saitoh

[the_rock]

No issues man, we are here to help. What do you see if you do basic capture? Do the logs show anything?

Andy

[saitoh]

Hi @the_rock ,

I appreciate your comments.

I captured packets at three points (Windows vNIC, CP's eth1, FortiGate's internal), only to find ICMP request from 10.31.10.1 (WindowsVM).

Your comment makes me notice I did not capture it at FortiGate's external.

I am going to do it and post the results.

The log of CP tells me that it allows ICMP request, but ICMP reply is nowhere to be found.

Saitoh

[saitoh]

I took packet at 10.11.124.1, and found FGT actually replies nothing, while it passes that packet from receiving port to destination port.

However, its debug log associated with routing shows FGT drops reply packet during route decision process.

Its policy is Src;Any, Dst:Any, Service:Any, Always at the top, so there is no mistake in policy hit.

I start to guess I misconfigured FGT's static routing, which was below.

To 10.31.10.0/25,

Gateway port2 (leading to CP's eth0) Distance 10

Gateway port3 (leading to CP's eth2) Distance 11

Port3 route is meant to be passive route even though I believe the route does not appear in routing table.

I guess this is not causing trouble because I thought in route decision session existence came in first.

I tried changing it as they have same AD, and things started going right!

Looks like kernel routing table should have active route through port3.

I am relieved to know I misunderstood FGT, not CP!

Many thanks for your help.

Saitoh

[saitoh · Accepted solution]

Dear @Lesley , and @Chris_Atkinson ,

I solved the issue, which is about misconfig on FortiGate, nothing wrong with CP.

Thanks for your time, and input!

Saitoh

[the_rock]

Great job!