- Products
- Learn
- Local User Groups
- Partners
- More
Welcome to Maestro Masters!
Talk to Masters, Engage with Masters, Be a Maestro Master!
Join our TechTalk: Malware 2021 to Present Day
Building a Preventative Cyber Program
Be a CloudMate!
Check out our cloud security exclusive space!
Check Point's Cyber Park is Now Open
Let the Games Begin!
As YOU DESERVE THE BEST SECURITY
Upgrade to our latest GA Jumbo
CheckFlix!
All Videos In One Space
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
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:
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.
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?
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
Is 172.16.0.37 contained within the defined VPN domain of your gateway?
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.
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:
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.
About CheckMates
Learn Check Point
Advanced Learning
YOU DESERVE THE BEST SECURITY