PBR Rules/R80.30 and Hide NAT

[SCSupport]

Hi all,

I have been given an answer by Check Point support, however wondered if anyone could explain to me what the changes are and the consequences of turning SecureXL off in the future.

So - we migrated a customer to R80.30 from a R77.30 firewall.

They have a list of PBR rules.

An issue came up where certain traffic was being received on the correct interface, but was leaving on the incorrect one. There is a PBR rule to point the traffic back to the correct interface. (The traffic wasn't being picked up by another PBR rule, it was just following OS routes)

Turning SecureXL off fixes the issue.

Check Point support pointed me to sk163320.

The customer does indeed translate his source IP, but his PBR rules was always set on the existing, original IP and not the NAT'd IP.

It appears now that PBR is calculated after NAT, therefore on the NAT address - firstly, is my understanding correct?

The customer is abit dismayed at the fact he now needs to adjust all his PBR rules to work with translated NAT source address. He also queries why this is the case in R80.20 and above, what changed? and also if he turns SecureXL off, will PBR's still be calculated on the NAT'd source address? or will he need to keep PBR rules for original and NAT'd addresses?

[KennyManrique]

AFAIK, source NAT was always performed on Server Side, so your hide NAT should take place on the outbound interface.

You can look the following SK to begin:

https://supportcenter.checkpoint.com/supportcenter/portal?eventSubmit_doGoviewsolutiondetails=&solut...

Check Point should clarify if the behavior has been modified.

[SCSupport]

Hmmm, that conflicts with the SK article I attached above?

The situation is as follows:

All the NAT rules they have are STATIC, not HIDE NAT.

An example traffic flow is:

PBR rule states all traffic with source: 10.30.0.0/14 should go via eth7.

When SecureXL is turned on, traffic does not hit PBR rule and goes via default routing which is via eth6.

We now have asynchronous routing.

Turn SecureXL off - traffic is picked up by the PBR rule and now leaves via eth7.

sk163320 does not apply as this is static NAT.

Also, it works fine with SecureXL off. Why?

Running R80.30 Take 111

[PhoneBoy]

As of R80.20, we removed the option to permanently disable SecureXL.
Which means disabling SecureXL long-term is not an option.
If disabling SecureXL is your only workaround for something, involve the TAC immediately.

There were also some pretty significant changes in SecureXL from R80.20.
This had an impact on things like PBR.
I would assume sk163320 applies in your static NAT case as well.

[Wolfgang]

As @PhoneBoy mentioned, open a TAC case if disabling SecureXL solves this problem.

sk163320 described a changed behaviour on which interface the NAT of the source IP is done.

If the source IP is NATed on the inbound interface, PBR does what it should, because PBR is done after processing inbound interface. It looks like with SecureXL off it does like the known "old" way and did changing source on the outgoing interface, after PBR.

You can run a "fw monitor" to see where NAT is happened.

Wolfgang