This is probably a simple one, but we’ve just inherited an HA pair of PA-850s, running 10.1.10, and need to set things up so we can access the management (both web GUI and SSH) from our central location via an IPSEC VPN.
So far we’ve got the VPN in place and running, but I’m struggling to work out how to configure the PAs to grant access to the management IP.
I can see traffic arriving over the VPN with the correct destination, but there’s never anything going back the other way. So far as I can tell there are no “allow lists” of IPs to connect to the management interface.
Any suggestions on where to look?
Is there a return route in place? Is your source IP added into the Management Interface Permitted IP List on the 850s?
Add an appropriate interface management profile to the interface your tunnel is on you’ll then be able to access the gui via the IP assigned to the interface while connected to the tunnel
Make a loopback and assign it to the VPN zone. Just make sure to restrict access. IIRC you can assign a different IP scope to the group of folks needing to access it for the IP restriction.
Fun fact, if your network/dynamic routing is fucked you can you can ssh to the loopback then a 2nd ssh session from the MGMT interface from there to anything still reachable from it. Put the vlan interface on your core and you likely have a pretty solid “back door”.
Edit: this won’t fix your problem above, but would be a nice feature for accessibility and will give you the confidence to bring the network down from the confort of your own home.
You need to validate that there is a route to and from
The mgmt IPs. You need to validate that the security policy allows this traffic on both the local and remote firewall. Start with the traffic monitor and look for traffic to the mgmt IP address. See if it’s allowed or denied. See which interface it egresses. Then hop onto the remote firewall and do the same.
Is the VPN Palo to Palo or Palo to Cisco?
It’s actually SonicWall NSA to Palo. I can see the traffic is going over the VPN tunnel correctly, so it’s definitely just some config needed on the Palo side.
You said you could see the traffic arriving to the Palo. Is it hitting an “allow” security policy? Do you have a route on the Palo to return back to the SonicWall VPN clients?
It looks like it’s hitting an allow rule, and it’s the same one that appears to be used when accessing the management interface from a machine on the LAN at that location.
The “Application” in the log view just shows as “incomplete” which suggests that nothing beyond the initial connection request got through (which implies a routing issue, and that no response to the connection request got back to the source IP).
Have you routed the traffic back through the tunnel?
The route will just be sent to the interface of the VPN tunnel with no IP address.
In your virtual router - go to static routes - Add new route - Add your Subnet/s of your client network and choose the tunnel interface where you sent up the VPN.
That should resolve your routing issue.
There is also another issue…
In your ‘IPSec Tunnels’ - you may need to add a Proxy ID.
The Proxy ID is needed when the other device may be a ‘policy based VPN’ rather than a ‘routed VPN’.
Within the proxy ID, create a little tag ID and then add the IP address of the remote IP addresses and then add 0.0.0.0/0 for your main office. (Or the other way around depending on your set up.)
I hope that helps.
Turn on bytes sent and received. If receive is 0. Then return traffic not making it back to firewall.
Thanks for the tips - I’ve double-checked, and we do have static routes in place on the PA for the remote subnets at our main location (and also on the SonicWall config for the other way around).
When doing a traceroute from a machine that is local to the PA, I notice it goes through a couple of hops - first the gateway IP on the machine’s subnet, then a second IP which looks to be another interface on the PA, before finally reaching the management IP.
I’m wondering if this is where the issue is, and have tried adding the intermediate subnet to the routing as well, with no success.
I suspect we’ll eventually rebuild the configuration on the devices from scratch, but it would be good to hook them up to our monitoring in the meantime.
Ok, found the issue - the gateway IP for the management interface is on a switch that’s doing layer-3 routing, and doesn’t have a route for sending any traffic to the VPN. Thanks for all the assists - time to get more familiar with the Palo Alto management I think!