Create a Post
cancel
Showing results for 
Search instead for 
Did you mean: 
Highlighted

Mobile Access VPN users can't reach Internal network

Jump to solution

Hi Guys,

I'm currently facing an issue whereby my mobile access VPN users couldn't reach to my Internal network but DMZ network is fine. E.g. I couldn't ping 172.16.0.37 but can ping 11.1.1.123. Seeking advise on which part of my configuration is wrong.

CP configuration:

Mobile Access > Office mode (172.16.9.x) and DNS server is configured in the optional parameter already.

Policy:- Src: Access Roles (local users), Dst: DMZ_Net (11.1.1.0), INT_Net (172.16.0.0) , Service: Any,  Allow

Routing:- Dst Network: 172.16.0.0/255.255.0.0, Gateway: 10.1.1.102 (FG interface)

 

FG configuration:

Policy: Incoming Interface: External (10.1.1.102), Outgoing Interface: Internal (172.16.0.x) Src: All, Dst: 172.16.0.0, Service: All, Allow

Routing: 0.0.0.0/0.0.0.0, Gateway: 10.1.1.101 (CP interface)

 

Ping test case:

172.16.9.1 (mobile access vpn user) ping 172.16.0.37 failed!

172.16.9.1 (mobile access vpn user) ping 11.1.1.123 successful! 

 

Regards,

Darren

0 Kudos
1 Solution

Accepted Solutions
Highlighted

You need to ensure that 172.16.0.37 (or its containing network) is defined in your firewall's VPN Domain on the following screen, or the SNX client will never put it into the tunnel in the first place.  What is your VPN domain definition on this screen and what networks does it contain:

domain.jpg

If this still doesn't make sense, once the SNX client is connected, run command netstat -rn from the SNX client itself (not the firewall).  Is there a route leading to 172.16.0.37 via the tunnel or not?  If it is just hitting the default route it won't go into the tunnel because your VPN domain is not complete.

Book "Max Power 2020: Check Point Firewall Performance Optimization" Third Edition
Now Available at www.maxpowerfirewalls.com

View solution in original post

0 Kudos
6 Replies
Highlighted

Is traffic to 172.16.0.37  being dropped by policy on the gateway (logged drop) or never put into the tunnel by the client in the first place?  (no log)

Is 172.16.0.37 contained within the defined VPN domain of your gateway?

Book "Max Power 2020: Check Point Firewall Performance Optimization" Third Edition
Now Available at www.maxpowerfirewalls.com
0 Kudos
Highlighted

Hi @Timothy_Hall,

 

I never configure anything on the remote access community. Is it needed for mobile access ? 

My idea is to allow access to the internal network (172.16.0.0) & DMZ network (11.1.1.0) with access role (office mode). I’m able to ping  all my DMZ servers with the office mode IP (172.16.9.1) assigned to me.

Regards,

Darren

 

0 Kudos
Highlighted

Is 172.16.0.37 contained within the defined VPN domain of your gateway?

Book "Max Power 2020: Check Point Firewall Performance Optimization" Third Edition
Now Available at www.maxpowerfirewalls.com
0 Kudos
Highlighted

I don’t think so but given that the PC (mobile access users) successfully establish a tunnel with CP and was assigned with a local IP too via office mode, isn’t it considered as local connection already? 

CP is serving as an external & DMZ firewall while FG is serving as an internal firewall. CP is directly connecting to FG and no switches in between. 

0 Kudos
Highlighted

You need to ensure that 172.16.0.37 (or its containing network) is defined in your firewall's VPN Domain on the following screen, or the SNX client will never put it into the tunnel in the first place.  What is your VPN domain definition on this screen and what networks does it contain:

domain.jpg

If this still doesn't make sense, once the SNX client is connected, run command netstat -rn from the SNX client itself (not the firewall).  Is there a route leading to 172.16.0.37 via the tunnel or not?  If it is just hitting the default route it won't go into the tunnel because your VPN domain is not complete.

Book "Max Power 2020: Check Point Firewall Performance Optimization" Third Edition
Now Available at www.maxpowerfirewalls.com

View solution in original post

0 Kudos
Highlighted
Have you checked your anti-spoofing configuration?
0 Kudos