- Products
- Learn
- Local User Groups
- Partners
- More
What's New in R82.10?
10 December @ 5pm CET / 11am ET
Improve Your Security Posture with
Threat Prevention and Policy Insights
Overlap in Security Validation
Help us to understand your needs better
CheckMates Go:
Maestro Madness
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.
Leaderboard
Epsum factorial non deposit quid pro quo hic escorol.
| User | Count |
|---|---|
| 4 | |
| 3 | |
| 1 | |
| 1 | |
| 1 | |
| 1 | |
| 1 | |
| 1 | |
| 1 | |
| 1 |
Wed 26 Nov 2025 @ 12:00 PM (COT)
Panama City: Risk Management a la Parrilla: ERM, TEM & Meat LunchWed 03 Dec 2025 @ 10:00 AM (COT)
Última Sesión del Año – CheckMates LATAM: ERM & TEM con ExpertosThu 04 Dec 2025 @ 12:30 PM (SGT)
End-of-Year Event: Securing AI Transformation in a Hyperconnected World - APACThu 04 Dec 2025 @ 03:00 PM (CET)
End-of-Year Event: Securing AI Transformation in a Hyperconnected World - EMEAThu 04 Dec 2025 @ 02:00 PM (EST)
End-of-Year Event: Securing AI Transformation in a Hyperconnected World - AmericasWed 03 Dec 2025 @ 10:00 AM (COT)
Última Sesión del Año – CheckMates LATAM: ERM & TEM con ExpertosThu 04 Dec 2025 @ 12:30 PM (SGT)
End-of-Year Event: Securing AI Transformation in a Hyperconnected World - APACThu 04 Dec 2025 @ 03:00 PM (CET)
End-of-Year Event: Securing AI Transformation in a Hyperconnected World - EMEAThu 04 Dec 2025 @ 02:00 PM (EST)
End-of-Year Event: Securing AI Transformation in a Hyperconnected World - AmericasWed 26 Nov 2025 @ 12:00 PM (COT)
Panama City: Risk Management a la Parrilla: ERM, TEM & Meat LunchAbout CheckMates
Learn Check Point
Advanced Learning
YOU DESERVE THE BEST SECURITY