- Products
- Learn
- Local User Groups
- Partners
- More
Check Point Jump-Start Online Training
Now Available on CheckMates for Beginners!
Why do Hackers Love IoT Devices so Much?
Join our TechTalk on Aug 17, at 5PM CET | 11AM EST
Welcome to Maestro Masters!
Talk to Masters, Engage with Masters, Be a Maestro Master!
ZTNA Buyer’s Guide
Zero Trust essentials for your most valuable assets
The SMB Cyber Master
Boost your knowledge on Quantum Spark SMB gateways!
As YOU DESERVE THE BEST SECURITY
Upgrade to our latest GA Jumbo
CheckFlix!
All Videos In One Space
Halo All,
I was enable Mobile Access Blade for SSL VPN and follow the wizard.
And this is the traffic : USER (public) —INTERNET— Mobile Access (R81.10) — Core — Internal Apps.
Mobile Access has 2 interface :
And Mobile Access configuration like below :
Enable Office Mode + IP Pool
My question is, why all Mobile Access user when access to internal apps detected using ETH2 IP (Local IP) not Pool VPN IP? When i check on Mobile Access Log, there are only Public IP information from user.
Based on above information, is my configuration wrong? any additional configuration needed?
Thankyou!
Both, Automatic NAT and Manual NAT should be used simultaneously. But if the properties of your Office Mode Pool look like the screenshot above, they are misconfigured. Use this one for references:
Set the Pool NAT properties as shown above, but add the NonNAT_Rule I have suggested previously.
If you are using Remote access with DNS forwarding to HQ and egress to the Internet resources, you want the pool to be NATed going outside. For access to internal resources, you do not- hence the Non_NAT Rule.
See Mobile Access R80.10 Administration Guide: Office Mode
Yes i just compared my configuration with admin guide.
On $FWDIR/conf/ipassignment.conf i make sure on this config file there is no configuration related to Local IP and Pool VPN IP. So in my opinion will take over by Manual (using IP Pool), but i dont know why on Application detect the user using ETH2 Local IP, not Pool VPN IP. This one make me confused.
I believe ipassignment.conf would take precedence.
Hi @Theo yeah i believe so earlier, but after check the $FWDIR/conf/ipassignment.conf there is no configuration related to IP that i used on the firewal..
This is the capture :
default setting ipassignment
Right, thats what every default ipassignment.conf would look like, so it does not appear it was modified manually.
Hello,
I assume you are using SNX or the Mobile Access vpn client on your remote machines in order to get an Office Mode IP address, it would be useful a capture what you see to understand better. I will assume you are checking only the logs for decrypted packets, maybe there is a NAT causing this behavior. To start you can go to the logs and look for blade:"Mobile Access" search your login and take note of the office mode ip assigned, then look for that IP address and check what you see, if there is a NAT you should find it here.
Regards
Likely a NAT issue.
I suggest creating a NO_NAT_for_Remote_Access rule in your NAT policy and configuring it as:
CP_Default_Office_Mode_Pool to Internal_Networks, Original, Original.
Agree, likely your hitting default/atuo NAT rules similar to:
Hi @Chris_Atkinson and @Vladimir
Thank you for your reply, currently i dont have access to the Gateway. i will it again on Thursday.
your suggestion is using manual nat or automatic nat? because i did some nat test before, by default VPN-IP-Pool is enable Hide NAT like below, but after i uncheck the NAT option, there is no differentiation. Is it similar with your suggestion using Manual NAT or Automatic NAT?
example - i did uncheck NAT option
Thanks!
Both, Automatic NAT and Manual NAT should be used simultaneously. But if the properties of your Office Mode Pool look like the screenshot above, they are misconfigured. Use this one for references:
Set the Pool NAT properties as shown above, but add the NonNAT_Rule I have suggested previously.
If you are using Remote access with DNS forwarding to HQ and egress to the Internet resources, you want the pool to be NATed going outside. For access to internal resources, you do not- hence the Non_NAT Rule.
About CheckMates
Learn Check Point
Advanced Learning
YOU DESERVE THE BEST SECURITY