Regarding gateway handling of asymmetric routing

[VannessChen]

Hi, Check Point Experts

I have a request and would like to seek your help and opinions.

Both the Client and Server are on directly connected networks of the Gateway. When the Client accesses an internal Server service via the Load Balancer (F5)'s virtual server IP, and without configuring S-NAT on F5 or PBR on the Gateway, how can we make the reply packet (blue line) return to the F5?

A simulated architecture diagram is shown below.

update:

After discussions between the CP team and the customer, the customer’s goal is to ensure that reply packets exit through the same interface the request packets entered from.

I’ve updated the interface port numbers in the network diagram:

• the request packet enters the Gateway via eth5 and is then forwarded to the Server.
• When the Gateway receives the reply packet from the Server, it should preferably be sent out via eth5 as well.

Is there a configuration method that can achieve this behavior?

[the_rock]

I always found issues like that to be related to incorrectly set topology.

Andy

[VannessChen]

Hi Andy
Thank you for your response.

This traffic flow works under the same conditions on FortiGate. Since the customer intends to replace FortiGate with Check Point, they are asking whether we can achieve the same behavior.

I’ve reviewed a number of documents but haven’t found any discussion specifically addressing this scenario.

[the_rock]

But keep in mind, with Fortigates, there is no setting like topology in CP smart console, even if you use forti manager to manage them, regardless if its onprem or cloud. In my personal experience, as long as routes and topology are right, this will work fine. 

Relevant discussion:

https://community.checkpoint.com/t5/Security-Gateways/Asymmetric-routing/td-p/166680

Andy

Andy

[Chris_Atkinson]

You may want to share the configuration options / choices used with the Fortigate in that case?

[VannessChen]

Hi Chris
According to the customer, FortiGate does not require any additional configuration to achieve this behavior. We are currently analyzing the FortiGate configuration provided by the customer to verify this.

[the_rock]

Personally, Im not aware of any additional control on CP either to achieve that behavior. Keep in mind that on Fortigate, you can enable asymetric routing globally, so maybe that have that on?

Andy

[Chris_Atkinson]

I think there is some confusion on the use of terminology or the topology is different / involves VRFs?

If the F5 or something else doesn't alter the src (or other parameters) of the request of course the return from the server will follow the normal routing table direct towards the client subnet.

[VannessChen]

Hi Chris

It appears that FortiGate prioritizes routing reply packets based on the session table, rather than strictly following the routing table. I believe this is the behavior the customer is aiming for, which is why they want to confirm whether Check Point can achieve the same functionality.

[_Val_]

I am sorry, what is the exact challenge here? If routing is configured properly, it should work out of the box, shouldn't it? What do I miss?

[VannessChen]

Hi Val

Based on the network diagram I provided, the customer wants to achieve symmetrical routing (same path for request and reply) without configuring S-NAT on the F5 and without setting PBR on the Gateway.

Can Check Point route reply packets based on the session table, rather than strictly relying on the routing table, to achieve this behavior?

[the_rock]

I dont see why not...thats how whole concept of stateful inspection is designed to work.

Andy

[Chris_Atkinson]

Not exactly.

I suspect if it's possible at all it would be a secureXL kernel parameter, might be a topic for TAC / RFE.

[VannessChen]

Hi Andy:

Since the source IP remains unchanged throughout the entire request path from the Client, when the Server sends the reply packet back to the Gateway, the Gateway routes it directly to the Client based on the routing table.

If the packet is not returned to the F5, the F5 will drop the entire connection because it does not receive the ACK packet.

You can refer to the tcpdump I captured in the lab for more details.

[Chris_Atkinson]

The problem is clear.

If it was me I would prefer not to design the network based on a particular vendor implementation to avoid lock in.

[PhoneBoy · Accepted solution]

As for the fact Fortinet handles this "out of the box," the question I have is: at what security cost?
Given the number of critical vulnerabilities known to be exploited in their products, I personally think it's a fair question.

ElasticXL (in R82) might actually handle this with the CCL (when the other gateway receives traffic and it's not the primary, it's forwarded to the primary).
Otherwise, what you're asking for is likely an RFE and the solution in the meantime is, in fact, using SNAT.

[the_rock]

100% fair.

[VannessChen]

Hi PhoneBoy

Thank you for the response.
We'll continue discussing the feasibility of this issue with the Check Point team today, and we hope for a good outcome.
Cheers!

[_Val_]

Ooookay, I see it now.

This is a weird topology. Why do you need to FW traffic to F5 twice, on both server and client side? It would only be reasonable to set F5 and the servers in the same segment.

[VannessChen]

Hi Val 

In the customer's architecture, if the Client wants to access the Server's service, it must do so via the F5's virtual server IP (used for load balancing).

There’s no issue when the Client is located on the outside of the F5, but as shown in the architecture diagram, if the Client is on the inside, it cannot access the service properly.