Unable To Connect to the Last IP Address of an Access-Route Subnet When Using GlobalProtect

• Access Route based Split tunnel is configured on GlobalProtect (GP) Gateway.
• The last IP address of an Access Route subnet is installed into the routing table as a Broadcast address.
• Due to this, the last IP address of the subnet cannot be connected and is unusable.
• Example: The Access Route is configured here for 10.50.60.20/25.

• Once connected to GlobalProtect, the Windows routing table shows that the broadcast address for this subnet has also been added, with the GlobalProtect interface as the next hop.

C:\Windows\System32> route print | findstr 10.50.60
  10.50.60.0    255.255.255.128    On-link    10.50.30.12    1
10.50.60.127    255.255.255.255    On-link    10.50.30.12    1

• When trying to access this IP in a browser, an ERR_ADDRESS_INVALID.

• Palo Alto Firewalls
• Supported PAN-OS
• GlobalProtect (GP) Gateway
• Access Route based Split Tunnelling
• Microsoft Windows

• Windows adds the broadcast address to the routing table when the local interface is added as next hop and does not allow TCP connections to a broadcast address.
• When static routes are added to the routing table with an external next-hop address, the route is added as-is without a broadcast address.
• When using a browser to access a non reachable, non-broadcast address, it times out, but when accessing the broadcast Address of 20.20.20.15, the browser shows an ERR_ADDRESS_INVALID.
• An example is provided in the additional section.

1. Design access routes so the broadcast address isn't used for a valid service.
2. For example, in a 10.20.0.0/24 network, a web server is hosted at 10.20.0.127.
3. If the design allows GlobalProtect users to access only 10.20.0.0/25, adding this as an access route will cause Windows to install a conflicting route for the 10.20.0.127 broadcast address.
4. When using small subnets like a /30, access routes can be separated into /32 routes if all IPs need to be accessed. A /32 route won't add a broadcast route and cause a conflict.

• Example below
• This machine has a local IP of 10.50.10.11.

C:\Windows\System32> route print | findstr IPv4
  IPv4 Address....................................10.50.10.11

• If a route is added with an external next-hop of 10.50.10.222, then the route is added to routing table correctly (No broadcast address added).

C:\Windows\System32> route add 90.90.90.0 mask 255.255.255.240 10.50.10.122 
OK!
C:\Windows\System32> route print | findstr 90.90.90
    90.90.90.0    255.255.255.240     10.50.10.122    10.50.10.11    26

• If a route is added with the local interface IP 10.50.10.11 as the next-hop, then Windows automatically adds a broadcast address:

C:\Windows\System32> route add 20.20.20.0 mask 255.255.255.240 10.50.10.11 
OK!
C:\Windows\System32> route print | findstr 20.20.20
   20.20.20.0    255.255.255.240     On-link    10.50.10.11    26
   20.20.20.15   255.255.255.255     On-link    10.50.10.11   281

• When accessing the a non-broadcast address of 20.20.20.14 using a browser, it times out as expected as this is just a dummy route.
• ERR_CONNECTION_TIMED_OUT shows that a connection was attempted, but it timed out awaiting a response.

• But when accessing the broadcast Address of 20.20.20.15, the browser shows an ERR_ADDRESS_INVALID error and no TCP SYN is transmitted.

• The reason that this can happen with GlobalProtect Access Routes, is that Access Routes are added to the routing table with the next-hop IP being the GlobalProtect interface Address, which is a local IP address.
• In the below example, GlobalProtect has an IP address of 10.50.30.12.

Ethernet adapter Ethernet:
   Connection-specific DNS Suffix .:
   IPv4 Address....................: 10.50.30.12
   Subnet Mask.....................: 255.255.255.255
   Default Gateway.................: 0.0.0.0

• The access routes below are 0/0 and 8.8.8.8/32 via 10.50.30.12, the local GlobalProtect address. Thus indicating routing is handled to these addresses by GlobalProtect.

Network Destination       Netmask       Gateway       Interface       Metric
    0.0.0.0               0.0.0.0     10.50.10.1    10.50.10.11       281
    0.0.0.0               0.0.0.0       On-link     10.50.30.12         1
    8.8.8.8        255.255.255.255      On-link     10.50.30.12         1