Who rated this post

Hello guys,

I have good news ... it looks like there is a solution 🙂

But first let me answer to @emmap :
Yes, this is weired ... but it does not look like my debian server is bouncing this reply ... but my SG (where I have PBR rule) - debian doesn't reseive this reply at all ... this reply hits 2nd router, then goes to 1st router (where debian is connected to), and then it goes back to 2nd router (so 1st router bounces this reply).

And now back to the solution:
As I mentioned I've created TAC case describing this issue even with more details then here.
It was couple of days ago ... until today there is no answer ... yet 🙂

But ....
I have another case with PBR that I didn't mentioned here to you ... maybe you will be interested in as well.
Case is about: "how to force Check Point that it will not do NAT for traffic related to PBR".

Let's assume that I have PBR configured as I described here in this post.... so I have enabled ABR and I have rule in fw where any traffic from debian should by matched by PBR and go to 2nd router.
And ... I don't want Check Point to do any NAT for this traffic.
Easy ? I thought so at the beginning.... but it looks like Check Point is not able to do that in one particular case (and unfortunately Fortigate has no issues with that at all 😜 ).
What's this particular case ? ... => Manual NAT rule.
If I have Manual NAT rule - for example like this one:

What should this rule do ?
NAT for any traffic FROM 10.20.200.0/24 (debian has 10.20.200.222) to ExternalZone.
Only eth1 (external) interface has ExternalZone.
eth0 has InternalZone - this is an interface that has 10.99.99.234 ... and via thius interface 2nd router (10.99.99.203) is reachable.
There is no other NAT rules in my lab configuration.
So I thought that in case traffic from eth2 (10.20.200.0/24) will be send to 10.99.99.203 via PBR (so to interface eth0) ... it will not match this NAT rule.
I was wrong ... unfortunately it looks like NAT is calculated before routing decision ... so even that traffic to 8.8.4.4 will go via eth0 .... it will be considered as traffic for ExternalZone ... sadly 😞

You may say ... so what ? let's create no-NAT rule before this one ... <-- sure in most cased it will be good idea ... but not in all of the cases. What about ICMP protocol ? And I don't want to create bunch of no-NAT rules before ....
I hope you get my point here...

Anyway ,... why I'm writing this NAT issue here ... in this post ?
HA HA becuase by accident I've found a solution to issue described in this post... 🙂

Take a look:

If you remember ... reply looked like this:
[vs_0][fw_0] eth0:i[44]: 8.8.4.4 -> 10.99.99.234 (ICMP) len=84 id=0
ICMP: type=0 code=0 echo reply id=10003 seq=1
[vs_0][fw_0] eth0:I[44]: 8.8.4.4 -> 10.20.200.222 (ICMP) len=84 id=0
ICMP: type=0 code=0 echo reply id=51307 seq=1
[vs_0][fw_0] eth0:o[44]: 8.8.4.4 -> 10.20.200.222 (ICMP) len=84 id=0
ICMP: type=0 code=0 echo reply id=51307 seq=1
[vs_0][fw_0] eth0:O[44]: 8.8.4.4 -> 10.20.200.222 (ICMP) len=84 id=0
ICMP: type=0 code=0 echo reply id=51307 seq=1

Right ? ... eth0 as incoming and OUTGOING interface ... no routing to eth2...

One minor change in configuration for PBR rule ... .and now it looks like this:
[vs_0][fw_0] eth0:i[44]: 8.8.4.4 -> 10.99.99.234 (ICMP) len=84 id=0
ICMP: type=0 code=0 echo reply id=10003 seq=1
[vs_0][fw_0] eth0:I[44]: 8.8.4.4 -> 10.20.200.222 (ICMP) len=84 id=0
ICMP: type=0 code=0 echo reply id=51307 seq=1
[vs_0][fw_0] eth2:o[44]: 8.8.4.4 -> 10.20.200.222 (ICMP) len=84 id=0
ICMP: type=0 code=0 echo reply id=51307 seq=1
[vs_0][fw_0] eth2:O[44]: 8.8.4.4 -> 10.20.200.222 (ICMP) len=84 id=0
ICMP: type=0 code=0 echo reply id=51307 seq=1

Perfect ! we have routing to eth2 !

What's this minor change ?
I just added additinal matching criteria to my PBR rule ...

SG> set pbr rule priority 100 match from 10.20.200.0/24
SG> show pbr rule 100
PBR rule 100 from 10.20.200.0/24 fwrule 1 table 1
SG> save config

And by accident ...it solved this issue !
root@debian:~# ping 8.8.4.4
PING 8.8.4.4 (8.8.4.4) 56(84) bytes of data.
64 bytes from 8.8.4.4: icmp_seq=1 ttl=117 time=17.3 ms
64 bytes from 8.8.4.4: icmp_seq=2 ttl=117 time=16.2 ms

Dear Check Point .... you should consider some more work on PBR ... because it is illogical in some aspects 🙂

I hope that my lab work will be helpful to somebody that will face similar problem 🙂

BTW
Any ideas about this NAT issue ? 🙂

--
Best
m.