I need to configure a PA5220 to allow users that are inside our network (on wifi) to connect to the VPN. Right now I have a zone for outside VPN users and a gateway and portal attached to our firewall outside interface. Our public DNS has an entry for vpn.corp.com that points to that interface IP. That all works great. I want to allow users inside the network to connect as well and my idea is to create a DNS entry inside our network that points vpn.corp.com to the firewall inside interface and create another portal, gateway, zone, and tunnel interface using the inside interface and it’s IP address. It seems like this should work but is there an easier way to accomplish this?
I would recommend looking at using an internal gateway without tunneling enabled and creating security policies based on user-id.
Create a no-nat rule for traffic from the Internal network to the public IP address of the firewall.
The next question that needs to be asked is- why? Is it for User-ID info or to access a separate secured network?
Having an Internal gateway can be pretty useful for a User-ID deployment or maybe to use host information profile (HIP) enforcement. They also can be used to encrypt traffic from the client to sensitive internal resources through a VPN gateway.
The way you described configuring a DNS entry is correct, This is referred to as GlobalProtect internal host detection, this is a feature that uses reverse DNS lookup on a Windows AD server or similar which will attempt the resolve the IP 10.x.x.10 to a FQDN, for example, gp-int.portal.mycompany.com and if successful the Global Protect Client will connect to the internal gateway, if the reverse DNS lookup fails the client will connect to the external gateway.
Check out my GlobalProtect VMware Workstation YouTube video that I just uploaded https://youtu.be/21m5hBEqvDY
Maybe I’m missing something, but why would they need to VPN in?
I have not tested your particular idea, but it sounds it should work. Be careful about accidental asymmetric routing in your setup.
The two solutions, proven to function, which you may find appealing are:
a) The concept of Internal Gateway(s), with, or without encrypting the traffic, as mentioned by Misterhonorable
b) The ‘No-NAT’ approach, as suggested by carmp3fan. In this scenario, you will continue using the existing Portal/Gateway. There will be no difference in setup/experience between users connecting inside and outside of your network.
In general, c2s internal, pre-logon VPN w/o split-tunneling represents the ‘ultimate’ Zero-Trust solution in some views. Hairpinning ensures inspection at the gateway level. Encryption protects data in transit from eavesdroppers. There will be several downsides to this approach, such as the inability of intermediate IPS appliances to inspect encrypted streams (which may not really matter if you rely on PAN Threat prevention). This is a rare design, but I have encountered it on few occasions.
If you are treating the WiFi as untrusted set up a no nat to external.
For more segmentation setup an eternal gateway for the WiFi and update the portal to include that gateway. Or setup a separate portal Make sure to prioritize the gateway and set it for that IP range.
Either way make sure the WIFI DNS does not resolve the internal gateway for internal use.
I would need to see a L3 diagram for a more detailed explanation.
Typed on mobile sorry for autocorrect
There’s a doc on how to do this somewhere, basically boomeranging out a nat policy.
Just write a none/none NAT rule destination as your currently VPN interface ip address (whatever vpn.corp.com resolves as).
internal gateway is useless unless you want to separate zone and security rules while devices outside and inside from the network
Reviving this thread for some help. I am too having issues with an internal gateway. The external gateway was already setup and working prior to my employment. I have been tasked with setting up an internal gateway for mobile devices. I have followed the lab video that @MBTechTalker posted closely other than creating a sub interface. I have gotten to the point where the mobile device detects the internal gateway and says connected, but it appears no traffic is getting out. When creating the no NAT policy and the security policy, traffic goes out, but the client doesnt show/say internal gateway. It appears it is just connecting to the external gateway as if they were on the outside. Not exactly sure what I am missing.
Right now for testing. If we go forward, it would be to allow some staff to work from their BYOD device which they will need access to some resources on the secured network that they don’t have access to currently on the BYOD wifi.
This would be for devices on a BYOD wireless network that doesn’t have access to any internal resources.
If the BYOD network won’t have access to resources directly then that makes sense.
Simply don’t NAT the BYOD network when they go to the public IP address of the firewall. It’s a problem I’ve seen and addressed this way repeatedly. Don’t create a U-turn NAT rule. It adds complexity and will force the client to use SSL instead of IPSec.
Why not create a separate SSID for those devices and use RADIUS ?