topic Re: Remote VPN client presents GW IP to other servers in the network in SASE and Remote Access

Remote VPN client presents GW IP to other servers in the network

PointOfChecking — Fri, 16 Apr 2021 10:32:57 GMT

Sorry if this has already been posted, but I can't find anything posted nor any admin guide which explains it.

We've got the Remote VPN set up, and clients connected successfully and working.

However, when we check logs of other servers, we cant see the IP of the remote client, just the Cluster IP (Main IP) of the GW.

So for example:

LAN Network address: 192.168.0.0/22 (192.168.0.0 - 192.168.3.255)

VPN Network Range: 192.168.2.0/24 (192.168.2.0 - 192.168.2.255)

GW (Main IP): 192.168.0.1

Proxy Server: 192.168.0.100

Remote Client IP: 192.168.2.1

LAN Client IP: 192.168.0.5

Both clients visit: www.website.com

When I check the proxy log, I can see 2 connections visiting www.website.com

- LAN Client IP: 192.168.0.5

- Remote Client IP: 192.168.0.1

So I can see clearly which LAN client accessed www.website.com, but I can't see which of the 254 remote Clients accessed that website, just someone on the VPN.

Is there a way to present the remote clients address (e.g. 192.168.2.1) to the proxy server?

Note that the LAN address is 192.168.0.0/22 which covers all addresses including those in the VPN range (192.168.2.0/24)

Thanks!

Re: Remote VPN client presents GW IP to other servers in the network

the_rock — Fri, 16 Apr 2021 12:18:17 GMT

That does not sound right...what is the remote access ip range you assigned for the clients? I had never seen this issue in all my years with CP.

Re: Remote VPN client presents GW IP to other servers in the network

PointOfChecking — Fri, 16 Apr 2021 12:41:09 GMT

Hi the_rock.

Sorry, I may have used the wrong terminology:

"VPN Network Range: 192.168.2.0/24 (192.168.2.0 - 192.168.2.255)"

The "VPN Network Range" is the "Remote access ip range".

Just to clarify:

- we're using R80.40 for MGMT and GWs

- from Logs and Monitor in SmartConsole I can see the different source IPs and Access Roles pick up correct LDAP information

- The problem is I can only see GW (MAIN IP) when checking logs of other third party servers (in the example in the OP, it was the proxy server in use)

Re: Remote VPN client presents GW IP to other servers in the network

Tobias_Moritz — Fri, 16 Apr 2021 13:22:07 GMT

I would check the NAT rules (manual and implicit ones).

Check the Check Point logs again and watch for xlate information.

It's definitly possible to not hide NAT vpn client traffic behind gateway when using Office Mode.

Re: Remote VPN client presents GW IP to other servers in the network

PointOfChecking — Fri, 16 Apr 2021 15:00:37 GMT

There aren't any NAT rules apart from the automatically created hide rule for the office mode range.

Based on your comment, I thought this might be the problem, so I added a rule higher above for:

SRC:OfficeMode DST:VPNDOMAIN any service =original =original =original

This didn't work, but made things worse, we lost all connections to the office.

Re: Remote VPN client presents GW IP to other servers in the network

PhoneBoy — Fri, 16 Apr 2021 16:36:13 GMT

What precisely was the VPN client installed as?
Can you confirm that access to other resources works as expected?
Have you used fw monitor to see what’s happening when the Remote Access client is trying to access something?

Re: Remote VPN client presents GW IP to other servers in the network

PointOfChecking — Mon, 19 Apr 2021 09:19:29 GMT

Hi PhoneBoy,

The client has been installed as Checkpoint Mobile

Access from the remote client to other resources in the Encryption domain work as expected.

All connections from the Encryption domain to the remote VPN addresses are failing. They're not even appearing in the logs.

I've attached a snippet of the Fw Monitor below for connections from remote client to LAN:

eth1 - LAN

eth4 - external interface

[vs_0][fw_4] eth4:i[44]: 192.168.2.1 -> 192.168.0.100 (TCP) len=47 id=54811
[vs_0][ppak_0] eth4:iD[40]: 192.168.2.1 -> 192.168.0.100 (TCP) len=40 id=54812
[vs_0][ppak_0] eth4:i[40]: 192.168.2.1 -> 192.168.0.100 (TCP) len=40 id=54812
[vs_0][fw_4] eth4:I[44]: 192.168.2.1 -> 192.168.0.100 (TCP) len=47 id=54811
[vs_0][fw_4] eth4:i[40]: 192.168.2.1 -> 192.168.0.100 (TCP) len=40 id=54812
[vs_0][fw_4] eth4:I[40]: 192.168.2.1 -> 192.168.0.100 (TCP) len=40 id=54812
[vs_0][fw_4] eth1:o[44]: 192.168.2.1 -> 192.168.0.100 (TCP) len=47 id=54811
[vs_0][fw_4] eth1:o[40]: 192.168.2.1 -> 192.168.0.100 (TCP) len=40 id=54812
[vs_0][fw_4] eth1:I[40]: 192.168.0.100 -> 192.168.2.1 (TCP) len=40 id=43340
[vs_0][fw_4] eth1:o[40]: 192.168.0.100 -> 192.168.2.1 (TCP) len=40 id=43340
[vs_0][ppak_0] eth1:Oe[40]: 192.168.0.100 -> 192.168.2.1 (TCP) len=40 id=43340
[vs_0][fw_4] eth1:O[40]: 192.168.0.100 -> 192.168.2.1 (TCP) len=40 id=43340
[vs_0][fw_4] eth1:Oe[40]: 192.168.0.100 -> 192.168.2.1 (TCP) len=40 id=43340
[vs_0][ppak_0] eth4:iD[40]: 192.168.2.1 -> 192.168.0.100 (TCP) len=40 id=54813
[vs_0][ppak_0] eth4:i[40]: 192.168.2.1 -> 192.168.0.100 (TCP) len=40 id=54813
[vs_0][fw_4] eth4:i[40]: 192.168.2.1 -> 192.168.0.100 (TCP) len=40 id=54813
[vs_0][fw_4] eth4:I[40]: 192.168.2.1 -> 192.168.0.100 (TCP) len=40 id=54813
[vs_0][fw_4] eth1:o[40]: 192.168.2.1 -> 192.168.0.100 (TCP) len=40 id=54813
[vs_0][fw_4] eth1:I[44]: 192.168.0.100 -> 192.168.2.1 (TCP) len=1350 id=60780
[vs_0][fw_4] eth1:I[44]: 192.168.0.100 -> 192.168.2.1 (TCP) len=388 id=60781
[vs_0][fw_4] eth1:o[44]: 192.168.0.100 -> 192.168.2.1 (TCP) len=1350 id=60780
[vs_0][fw_4] eth1:O[44]: 192.168.0.100 -> 192.168.2.1 (TCP) len=1350 id=60780
[vs_0][fw_4] eth1:o[44]: 192.168.0.100 -> 192.168.2.1 (TCP) len=388 id=60781
[vs_0][fw_4] eth1:O[44]: 192.168.0.100 -> 192.168.2.1 (TCP) len=388 id=60781
[vs_0][ppak_0] eth1:Oe[44]: 192.168.0.100 -> 192.168.2.1 (TCP) len=1350 id=60780
[vs_0][ppak_0] eth1:Oe[44]: 192.168.0.100 -> 192.168.2.1 (TCP) len=388 id=60781
[vs_0][fw_4] eth1:Oe[44]: 192.168.0.100 -> 192.168.2.1 (TCP) len=1350 id=60780
[vs_0][fw_4] eth1:Oe[44]: 192.168.0.100 -> 192.168.2.1 (TCP) len=388 id=60781
[vs_0][ppak_0] eth4:iD[40]: 192.168.2.1 -> 192.168.0.100 (TCP) len=40 id=54814
[vs_0][ppak_0] eth4:i[40]: 192.168.2.1 -> 192.168.0.100 (TCP) len=40 id=54814
[vs_0][ppak_0] eth4:iD[44]: 192.168.2.1 -> 192.168.0.100 (TCP) len=47 id=54815
[vs_0][ppak_0] eth4:i[44]: 192.168.2.1 -> 192.168.0.100 (TCP) len=47 id=54815
[vs_0][ppak_0] eth4:iD[40]: 192.168.2.1 -> 192.168.0.100 (TCP) len=40 id=54816
[vs_0][ppak_0] eth4:i[40]: 192.168.2.1 -> 192.168.0.100 (TCP) len=40 id=54816
[vs_0][ppak_0] eth1:Oe[40]: 192.168.0.100 -> 192.168.2.1 (TCP) len=40 id=60782
[vs_0][ppak_0] eth1:Oe[40]: 192.168.0.100 -> 192.168.2.1 (TCP) len=40 id=60783
[vs_0][fw_4] eth4:i[40]: 192.168.2.1 -> 192.168.0.100 (TCP) len=40 id=54814
[vs_0][fw_4] eth4:I[40]: 192.168.2.1 -> 192.168.0.100 (TCP) len=40 id=54814
[vs_0][fw_4] eth4:i[44]: 192.168.2.1 -> 192.168.0.100 (TCP) len=47 id=54815
[vs_0][fw_4] eth4:I[44]: 192.168.2.1 -> 192.168.0.100 (TCP) len=47 id=54815
[vs_0][fw_4] eth4:i[40]: 192.168.2.1 -> 192.168.0.100 (TCP) len=40 id=54816
[vs_0][fw_4] eth4:I[40]: 192.168.2.1 -> 192.168.0.100 (TCP) len=40 id=54816
[vs_0][fw_4] eth1:o[40]: 192.168.2.1 -> 192.168.0.100 (TCP) len=40 id=54814
[vs_0][fw_4] eth1:o[44]: 192.168.2.1 -> 192.168.0.100 (TCP) len=47 id=54815
[vs_0][fw_4] eth1:o[40]: 192.168.2.1 -> 192.168.0.100 (TCP) len=40 id=54816
[vs_0][fw_4] eth1:I[40]: 192.168.0.100 -> 192.168.2.1 (TCP) len=40 id=60782
[vs_0][fw_4] eth1:o[40]: 192.168.0.100 -> 192.168.2.1 (TCP) len=40 id=60782
[vs_0][fw_4] eth1:O[40]: 192.168.0.100 -> 192.168.2.1 (TCP) len=40 id=60782
[vs_0][fw_4] eth1:I[40]: 192.168.0.100 -> 192.168.2.1 (TCP) len=40 id=60783
[vs_0][fw_4] eth1:Oe[40]: 192.168.0.100 -> 192.168.2.1 (TCP) len=40 id=60782
[vs_0][fw_4] eth1:o[40]: 192.168.0.100 -> 192.168.2.1 (TCP) len=40 id=60783
[vs_0][fw_4] eth1:O[40]: 192.168.0.100 -> 192.168.2.1 (TCP) len=40 id=60783
[vs_0][fw_4] eth1:Oe[40]: 192.168.0.100 -> 192.168.2.1 (TCP) len=40 id=60783
[vs_0][ppak_0] eth4:iD[40]: 192.168.2.1 -> 192.168.0.100 (TCP) len=40 id=54817
[vs_0][ppak_0] eth4:i[40]: 192.168.2.1 -> 192.168.0.100 (TCP) len=40 id=54817
[vs_0][fw_4] eth4:i[40]: 192.168.2.1 -> 192.168.0.100 (TCP) len=40 id=54817
[vs_0][fw_4] eth4:I[40]: 192.168.2.1 -> 192.168.0.100 (TCP) len=40 id=54817
[vs_0][fw_4] eth1:o[40]: 192.168.2.1 -> 192.168.0.100 (TCP) len=40 id=54817
[vs_0][ppak_0] eth4:iD[44]: 192.168.2.1 -> 172.21.1.10 (UDP) len=76 id=51122
[vs_0][ppak_0] eth4:i[44]: 192.168.2.1 -> 172.21.1.10 (UDP) len=76 id=51122
[vs_0][fw_4] eth4:i[44]: 192.168.2.1 -> 172.21.1.10 (UDP) len=76 id=51122

When I ping from LAN to remote client I get the below:

LAN PC: 192.168.0.5

Remote Client: 192.168.2.1

[vs_0][ppak_0] eth1:i[44]: 192.168.0.5 -> 192.168.2.1 (ICMP) len=60 id=9278
[vs_0][fw_0] eth1:i[44]: 192.168.0.5 -> 192.168.2.1 (ICMP) len=60 id=9278
[vs_0][ppak_0] eth1:Oe[44]: 192.168.0.5 -> 192.168.2.1 (ICMP) len=60 id=9278
[vs_0][fw_0] eth1:I[44]: 192.168.0.5 -> 192.168.2.1 (ICMP) len=60 id=9278
[vs_0][fw_0] eth1:o[44]: 192.168.0.5 -> 192.168.2.1 (ICMP) len=60 id=9278
[vs_0][fw_0] eth1:O[44]: 192.168.0.5 -> 192.168.2.1 (ICMP) len=60 id=9278
[vs_0][fw_5] eth1:Oe[44]: 192.168.0.5 -> 192.168.2.1 (ICMP) len=60 id=9278

Re: Remote VPN client presents GW IP to other servers in the network

PhoneBoy — Mon, 19 Apr 2021 15:41:58 GMT

If I'm reading this right, it's getting dropped before the big O on the inbound direction.
What does an fw ctl zdebug drop | grep client-ip says is the reason for this?
If nothing is shown, I recommend a TAC case for further troubleshooting.

Re: Remote VPN client presents GW IP to other servers in the network

PointOfChecking — Thu, 22 Apr 2021 10:58:28 GMT

Hi PhoneBoy,

So we found that it was a routing issue. We had to add a route to the hosts on the LAN to point to the GW.

192.168.2.0/24 -> 192.168.0.1

The question is, as the LAN network range is 192.168.0.0/22 (which includes 192.168.0.0 - 192.168.3.255 addresses)

This covers the VPN network range 192.168.2.0/24 (192.168.2.0 - 192.168.2.255).

Why do I need to add the route?

We currently have a VPN server from another manufacturer where the config works without having to add the route.

When I ping a host connected via that server I'm able to see the remote client added to my ARP table.

When I ping a host connected via the Checkpoint VPN, (after adding the route to my PC), the ping works, but the remote client does not appear in my ARP table.

Re: Remote VPN client presents GW IP to other servers in the network

PhoneBoy — Thu, 22 Apr 2021 19:44:32 GMT

What is the precise network configuration between the LAN clients and the gateway?
Sounds like it's really a flat network (i.e. the gateway and the LAN clients are on the same network), is that correct?

In which case, that route is one way to solve it.
Proxy ARPs on the gateway are another.
I don't believe either of these things happen automatically as the Office Mode subnet is usually on a different segment from the directly connected LAN.

Re: Remote VPN client presents GW IP to other servers in the network

PointOfChecking — Fri, 23 Apr 2021 07:28:34 GMT

Hi PhoneBoy,

Appreciate your time with this question.

It is indeed a flat network. We've scheduled a change to update the routing on all the routers next Monday. So should have this resolved.

Thanks for the tip about Proxy ARP, that might have been an easier and quicker solution. Thanks again!

EDIT:

Just tried the Proxy ARP and can confirm it works, but there isn't an option to configure for the entire subnet: 192.168.2.0/24

If we were to use this solution, we'd have to manually add Proxy ARP records for all 254 IP addresses.

May be in new update, we could request to add the facility to configure Proxy ARP for entire subnets? Or would there be problems doing that?

Thanks again