Wrong SGM for return traffic

[Martijn]

Hi Community Members,

Customer has the following Maestro setup:

- Single site
- Dual MHO
- Four 29100 appliances
- VSX
- R82 take 122
- One Security Group
- 11 Virtual Systems
- Distribution Mode manual-general, Layer 4 enabled (No NAT, no VPN)

This setup is handling 1.2 M concurrent connections without any problems. Except for return traffic from one connections. Let me try to explain.

Customer has two main RADIUS servers in the network for authentication users and computers, which works fine.
In other part of the network more RADIUS servers are installed that forward the request to the main RADIUS servers. These forwarded requests are send through a Virtual System on the Maestro setup.

192.168.10.2:43526 -> 172.20.10.5:1812 for example. Not the real customers IP.

With 'asg dxl calc' we see that SGM 1_3 and 1_4 are selected for this traffic. The same for the return traffic 172.20.10.5:1812 -> 192.168.10.2:43526. So this looks OK.

But sometimes return traffic for these connections is handeled by SGM 1_1 (as seen in SmartLog) which results in a out-of-state message because SGM 1_1 does not know the connection.

We have checked the whole setup but cannot find anything wrong. All other connections through the same Virtual Server are OK. And the 1.2 M other connections through the same setup are OK.

We have one possible suspect. The main RADIUS server (in my example 172.20.10.5) is also the primairy RADIUS server configured on this Maestro set for authentication. And this traffic is handeled by the SMO which is SGM 1_1. This sounds not very logical because that is VS0 en not the Virtual System handeling the other RADIUS traffic.

The problem comes and goes and it is hard to troubleshoot. When it occurs it has a major impact on users and computers because they cannot authenticate and/or access the network. So for now a rule is configured for the return traffic with high-ports as the destination port. And we see that rule is hit and the SGM is always 1_1.

Anyone an idea what could be  wrong here? Has anyone seen this before?

Regards,
Martijn

[Timothy_Hall]

That problem will be tough to find due to its intermittent nature.  What you could try, if you know the attributes of the problematic sessions, is to always "stick" those connections to the SMO Master with asg_excp_conf, regardless of what the distribution algo does (or sometimes doesn't do in your case).  There used to be an SK describing this procedure (sk175584: Forwarding specific inbound connections to the SMO Security Group Member), but it seems to have been deleted or hidden.  If it is hidden, you could try hitting up your SE for a copy.  Here is the only documentation still around for this command:

https://sc1.checkpoint.com/documents/R82.10/WebAdminGuides/EN/CP_R82.10_ScalablePlatforms_AdminGuide...

[Martijn]

Hi Timothy,

Thanks for your reply. I agree. Very difficult to investigate. 

I have checked the rule configured as the work-around and it is only hit once a day at the moment. But we will keep monitoring this.

For now we will keep the work-around. Source and destination are known system in control by the customer. And there are other firewall in this path so the risk is low.

Martijn

[CheckPointerXL]

Delayed reply from radius server causing timeout in connection table for that radius traffic?

[Martijn]

Hi,

We don't think so. When we check with 'asg dxl calc' the initial connection and return traffic should be handeled bij SGM 1_3 and 1_4. But when the return traffic is dropped, it is dropped bij SGM 1_1.

Se even if there is a delay, SGM 1_3 and 1_4 should be used for this delayed return traffic.

Because the problem is not always there, it is very hard to investigate with for example fw monitor or tcpdump.
For now we leave the work-around in place.

Martijn