1800 SMB set source ip for connections originating from cluster

[vladdar]

Hello all,

I am trying to figure out how the connections are originated from checkpoint SMBs.

I have a scenario. I am using RADIUS authentication for RA VPN and the radius packets towards customer LAN (where the radius server is) are sourced from the SYNC subnet (subnet that is used for cluster sync). Usually, the customer LAN would be directly connected and source IP would be from this subnet, but in my case cust. subnet 10.3.0.0/24 is routed over another p2p subnet because we are in migration phase. As a result my connection is sourced from IP of the wrong interface (LAN2/SYNC).

How can I change the source IP of the radius auth requests? Source NAT does not work (I am using strict  fw rules and automatic hide NAT is off). Boxes are locally managed.

10:17:56.073707 IP my.firewall.58523 > 10.3.0.96.radius: RADIUS, Access-Request (1), id: 0xde length: 56
10:18:01.075881 IP my.firewall.58523 > 10.3.0.96.radius: RADIUS, Access-Request (1), id: 0xde length: 56
10:18:06.077731 IP my.firewall.58523 > 10.3.0.96.radius: RADIUS, Access-Request (1), id: 0xde length: 56

# ping my.firewall
PING my.firewall (10.231.149.1): 56 data bytes
64 bytes from 10.231.149.1: seq=0 ttl=64 time=0.062 ms
64 bytes from 10.231.149.1: seq=1 ttl=64 time=0.057 ms

Thanks.

[_Val_]

Let's cover basics first. Version, locally or centrally managed?

[vladdar]

The current firmware version is R80.20.35 (992002577)

locally managed

[_Val_]

Thank you. So what is the problem, RADIUS does not recognise those different IPs? Or something else?

[vladdar]

Problem is that it is inconvenient because of the administration overhead. Customer has to allow and route new subnet. Subnet which should be used just for the interconnection of the cluster members.

This does not make sense to source connections from those IPs.

[_Val_]

Source IPs are based on interfaces used to communicate with the server. When and if you change the topology and eliminate the network in the middle, it should be back to normal.

[vladdar]

Yes I am counting on that.. But this: "Source IPs are based on interfaces used to communicate with the server" is not true right know. p2p interface towards customer is LANBOND0.3 interface and that is where the route towards server points and i would assume this would be the source of the connection but actually the source is SYNC interconnection interface between cluster members which is very weird. But if it cannot be change of course workaround is possible, it's just inconvenient.

Thanks Val.