To start with I just want to say I'm also working with Palo Alto on this, but figured I would come here in case someone has experience with these two:

We have recently installed a PA 5020 Firewall and while working on the Global Protect (GP) VPN are unable to get the 2 (Direct Access and GP) VPNs to function properly.

On a machine outside of the corp with no Direct Access configurations and only having GP everything works fine. DNS checks out and you have solid IPv4 routing to all of our desired networks we want access to.

On a machine that has strictly Direct Access running everything works as it has before with us able to access all the desired resources we want and were previously able to. Able to ping domain names and return with IPv6 as expected.

Now the problem comes when you try to connect the 2nd machine that has DA to GP. GP will connect properly and you have IPv4 connectivity to all devices listed in the routes that are published to it, however DNS breaks at this point. You are unable to resolve any DNS name (flushed the dns then try to ping a name and it fails), if you do a nslookup on the same name our internal DNS server does respond and provide the proper IP.

I think part of what is causing the problem is that Direct Access doesn't fully turn itself off as it should. When we had Cisco AnyConnect we had no problems and DA would shut itself after you connected to AnyConnect as it would see itself as "inside" due to it having inside access through the AnyConnect tunnel. With GP though DA still sees itself as being outside the network and does not properly disable, but while not disabled it is also not all the way connected as the various tunnel adapters are shown as disconnected and their is no MM/QM under the Security Associations within the Firewall settings.

Any suggetions would be greatly appreciated!

Hi,

Have you verified that you can reach the NLS server from the DA client with GP activated?
Sounds like your NRPT rules still are active and queries for internal hostnames are sent to the DirectAcces servers.

Best wishes,
Jonas Blom

I believe I did try to reach the NLS while GP was on but it failed. I will verify this tonight though and update. <o:p></o:p>

If nothing else doing some quick reading on NRPT it does have the potential to cause problems like what Im experiencing.

Thanks much<o:p></o:p>

I looked at this the other day using the show namespace and it did appear to be using the Direct Access settings (had IPv6 addresses listed in output).

Also confirming this is that the only name to resolve is NLS (correcting my last statement). This is resolved over IPv4 (the GP connection), this makes sense due to the fact that nls is listed within the Direct Access configurations.

Hi again,

Make sure that you can reach (ie, browse to with internet explorer) the NLS website and that the certificate is valid.

It is good that the dns entry is resolved correctly, but one of the things I was after was that the NLS isn't blocked in the GP solution somewhere.
(By a firewall rule for example)

Best wishes,
Jonas Blom

Thanks for the reply.

I will check the NLS through the browser.

I can confirm that we have allowed everything from VPN to the intranet webserver which is where the NLS is at. Also since are doing HTTPS decryption I confirmed that this set of traffic is within our exclusion rules so is not being decrypted (I know some applications/sites hate having the Certificate messed with).

I don't know your status right now, but in your scenario it is important that the local name resolution option in DirectAccess is configured correctly. In step 3 of the DirectAccess wizard make sure it is set to..

Fall back to local name resolution if the name does not exist in DNS or the DNS servers are unreachable when the client computer is on a private network (recommoneded)

This setting is important because your NRPT is configured to exclude the NLS URL. You want to be able to fall back to your internal DNS Servers that come with your VPN connection. Although I must add, it is set by default unless you changed it.

Another thing to check is het binding order of your network interfaces.

This is currently a known problem and a Feature Request at Palo Alto.