Alright, this is basically a rant..
I installed a PA-500 at a site this last weekend, replacing a Cisco ASA 5520. We are using this site as our test bed for the 4.1 codebase before rolling it out company-wide. To be honest, I'm in no hurry to move from 3.1, but we ran into a problem where 3.1.10 would not properly translate H.323 traffic through NAT, and I (the network administrator) can't log in remotely with the SSL VPN because it fails to assign a private IP address on both my Windows 7 laptop and XP desktop at home. (I suspect this is because, by sheer coincidence, my subnet is the same as the company's -- 10.0.0.0/8. Yes, it's atrocious overkill for a home network, but now I think of it as a stress test for VPN software.)
4.1.3 fixed the NAT problem, and I'm hoping to have more luck with the new Global Protect client. But, I traded those two known evils for a host of new ones...
For one -- OK, this isn't specific to 4.1 actually -- there is no support for DHCP options in the DHCP server. I was able to fall back to using a Juniper switch to serve DHCP, but I'm surprised to see such a glaring omission. VoIP isn't new anymore. Or even booting via PXE. The onus is on me for not noticing this earlier, but it never occurred to me that it wouldn't be supported. I searched other menus thinking I had to be missing something obvious, but nope. It's just not there.
Then, more trouble with commits. It's still hit and miss whether the commit will succeed. This is completely unacceptable from a production device. I would expect this in a beta, but after so many 4.0 releases, then to 4.1, and now being at 4.1.3, why isn't this ironed out yet? Commits shouldn't fail. Ever. Rejected, sure. But not fail. I've been told 4.1.4 should fix this, but if you look at the release history, commit failures are fixed in every release, so we'll see.
On top of that, I managed to crash the management engine. On Monday morning, I realized I had forgotten to turn off the DHCP server on the VoIP VLAN -- the phone switch usually handles this, but I had it enabled on the PAN for testing. I make this one simple change. Sure enough, commit hangs at 70% via the web GUI. I try the CLI and I'm told a commit is in progress after several minutes. Finally, I'm able to try again. Commit shows progress (.....50%...70%...) then get a line and a half full of dots, and commit failed: timed out. The status light on the front is lit yellow, and the next attempt closes my SSH window as if I had logged out.
So, 30 minutes into its first business day in the rack and I'm sending a notification to the entire office that the network will be down for a reboot. I'm not impressed. I've been petitioning management to buy PA-200s for the satellite offices... I'm wondering how convincing an argument I have now.
Whilst I cant help with the majority of your problems I can tell you that the Global Protect client appears to be able to work out when the address it allocates conflicts with the local addressing (as in the case where both the local & remote nets use 10.x.x.x) and will try an alternative address provided you have allocated another range in the gateway - so I have our gateways setup with a 10.x.x.x address range and a 172.x.x.x address range, which seems to work. We are increasingly seeing the 10.x.x.x addresses being allocated by hotspots & wireless carriers in the UK, so its definately something to test !
I appreciate the idea, but that wouldn't work in our network.
We have two datacenters that act like a kind of hub-and-spoke topology. Many, many sites connect in and have routed networks that need to communicate with the two DCs. Our entire network is in 10.0.0.0/8, with subnets carved out for the various locations. We use route summarization a lot to simplify routing tables, since we have a mixed network that won't support OSPF end-to-end, and thus, for now, use static routes. They would be much more complicated if we couldn't rely on each site address pool being a supernet-able block.
Beyond that, we already use other private IP spaces for various things -- like 192.168 for site guest networks that can't route back to the DCs; and 172.16 networks to create VPNs to partner sites when a contract requires it, etc. So, using other spaces that need to be routable throughout the network would really throw a wrench into the works.
Foremost, I've never had a problem with the Cisco IPsec client assigning an address on a client with overlapping networks, so it's obviously not a technical impossibility, it's just something the Palo Alto client software wasn't designed to handle.
Click Accept as Solution to acknowledge that the answer to your question has been provided.
The button appears next to the replies on topics you’ve started. The member who gave the solution and all future visitors to this topic will appreciate it!
These simple actions take just seconds of your time, but go a long way in showing appreciation for community members and the LIVEcommunity as a whole!
The LIVEcommunity thanks you for your participation!