So we just got a demo 1410 to see if we’re able to use it as a replacement for our EoL Ivanti boxes. Don’t get me started on Ivanti!
We will only be doing VPN on 1410, no Ingress/Egress firewalling, threat prevention, Web filtering, etc will be done on them. All of that is being handled by our Enterprise firewalls which the 1410 will be hanging off of on a DMZ which brings me to my design and question(s).
Ideally we’d like this to be a parallel replacement for Ivanti in that it would connect and handle traffic the same way. Reason being is that we have tons of ACLs, etc that are verify specific on what subnets are allowed to talk to other subnets, etc. So we want to keep the subnet VPN users are assigned the same whether or not you’re connected to Ivanti vs Global Protect.
In reading I also just discovered that the ability to use a DHCP Server to assign IPs to GP clients just became a feature in 11.2! So the 1410 is now running 11.2.3, yeah I know we’re asking for it! But we need the feature and YOLO, right? You’re also welcome we’re beta testing for you! 
Here’s little diagram of how Ivanti is currently setup.
Ivanti Client ->Internet–>Public Address–> Firewall --NAT–> DMZ->Ivanti Outside Interface 10.10.10.10/24)–>Ivanti Client (192.168.1.50/24) → Ivanti Inside Interface (192.168.1.10/24)–>Inside Switchport → Core Router (192.168.1.1/24)
So essentially when an Ivanti client connects they’ll get an IP from 192.168.1.0/24 (via the Enterprise DHCP Server) and placed on the same subnet as the Ivanti Inside interface and dumped onto the network.
Am I able to do this same sort of setup on PAN? Looking at some config guides I need to setup either a loopback or tunnel l3 interface for VPN traffic and I’m just not sure how that all plays together since the Internal physical interface is the same subnet (192.168.1.0/24) as what the GP clients would have.
I’m totally open to whatever design needs to be done just as long as the GP clients end up having the same IPs as the Ivanti ones.
I’m here to test so let’s hear some ideas!
Thanks guys!
Do they need the samne IP’s or do they needs IP addresses from the same subnet? Why is it important to utilize the Corporate DHCP server instead of using the pool assignment mechanism ? Are you doing per user dhcp reservations? I’m honestly not even sure how that would work as the MAC addresses that show up in GP is not relevant like a real MAC address is.
Why use 192.168.1.1/24, easily the most common remote user home address range for VPN? Wow, that’s just asking for helpdesk calls.
I do consulting and work a lot with PA’s.
My first impression is that the difficulty you are facing is because you have artificial requirements that require you to have a narrow solution focus.
My suggestion would be to zoom out and analyze this from a more basic principle standpoint, like asking why these are the requirements and if we can creativly solve this…
But a simple answer would be… take one address from your /24 and use NAT for new FW while doing the migration amd set the client pool to anything else, then replace the pool when the old FW is offline
Let me clarify…
They need to be coming from the same subnet. That subnet is managed from our DHCP Server. If I for instance shrink the DHCP scope size and make that an IP pool handed out by the 1410 I’ve limited the total available for Ivanti which could lead to capacity issues in the short term.
I think the big issue here is that having the same subnet attached to multiple interfaces (physical, virtual)
Also, we use Infoblox and having everything IP / User related in one spot is very valuable and not something we want to stray from.
No reservations, all dynamic.
Oh, all the addresses I picked above were made up, I just wanted to make sure there was contrast to what I was talking about!
Thanks!
Understood. So your real issue can be restated as we want to have both the Ivanti VPN and Palo Alto VPN systems up and online at the same time during transition. However, having a single vlan exist in two places at once is a technical challenge.
I would say you are going to have to bite the bullet here. Perhaps changing your /24 into a 4 /26’s and migrate them over slowly may be an option. As in day 1, all 4 /26’s on Ivanti, day 2, 3 on Ivanti, day 3 2 on Ivanti, day 4, 1 on Ivanti, day five fully cut over. Of course you would need to manage the routing for the “192.168.1.0 le 24” subnets into your core so that your internal network would know which VPN platform to return traffic to.
That would be a pain, but perhaps at least give you a path forward. I still would use the Palo pool mechanism to hand out IP addressing if it were me. I also would reduce the lease times very low, like perhaps even as low as 30 minutes to keep as much free as possible. Once a client connects, as long as they are online and stay online the client will refresh at halfway and re-request the same IP and be refreshed. Only if they disconnect for the 30 minute lease duration would it free back up.
A combination of those strategies might be able to get you through the transition.
Hmmmm… I’m not sure I’m following you on the single VLAN thing. That particular VLAN (like all of our others) exist on all of our switches so I can have as many ports configured for them as I want. The Ivanti and the PAN both have interfaces in it just like any other device plugged in. L2 trunks everywhere and L3 happening in the core.
Does that help/change what you’re thinking?
Your problem is that you want to make the same subnet exist in two places. You can configure the Ivanti and Palo so issue client addresses from the same subnet - but how does the core get traffic back to them?
What will the core route table say for 192.168.1.0/24? Will it send that to the Ivanti, breaking all the Palo clients, or vice versa?
A possible kludge to get you through migration - change the DHCP scope available to the Ivanti to 192.168.1.0/25 plus 192.168.1.128/26 plus 192.168.1.192/27 plus 192.168.1.224/28 plus 192.168.1.240/29.
Then, issue 192.168.2.0/24 to the Palo GP clients, and NAT/PAT them to an address no longer assigned to the Ivanti.
I have nothing else helpful to contribute.
The L3 interface exists on our core and the Ivanti & PAN are just clients on the L2, there’s no route pointing to the Ivanti. When I look at the ARP table (on the core) all the Ivanti client IPs show up with the MAC of the Ivanti. So same thing for when I setup the PAN on that VLAN.
DHCP will hand out an IP to a GP client and then that IP would be seen with a MAC from the PAN. Same deal.
I shouldn’t have to futz with anything to do with DHCP, L2, L3 on my existing infrastructure.
Or am I on drugs? haha
Thanks!
Talking this out got me thinking and the Ivanti is really just asking like a switch where as PAN is is routing which is where my dilemma is.
Can I use a L2 interface on the Inside and have this same functionality? Or is that just a bad idea and I should bite the bullet and totally start fresh?
You get it right, the Ivanti has L2 but PAN has L3. Unless devices behind the Ivanti needs to communicate with the devices behind the PAN this is manageable. Basically you need to gradually split the net to route to the PAN as you move tue clients. And easier if you choose to let the PAN do the dhcp for the addresses it has.
You can definitely have layer 2 interfaces and make an svi on the PA. I’m not sure how to have gp land in the se subnet as am on prem subnet. I know when a firewall is a router on a stick setup you have to make more trust to trust rules.