Globalprotect end users are receiving default route (0.0.0.0) but it is not configured to do that

Announcements

Changes to the LIVEcommunity experience are coming soon... Here's what you need to know.

Reply
axelrafaeltadoy
L1 Bithead

Globalprotect end users are receiving default route (0.0.0.0) but it is not configured to do that

Hello masters,

I need your help on how to troubleshoot an issue related to global protect.

 

On our Access routes, no 0.0.0.0 are configured.

We wanted to let users use their local gateway for any traffic destined to the internet.

But they are receiving the 0.0.0.0 in their RoutePrint resulting to traversing their any traffic to the VPN.

This is clogging our network.

I already engaged 3 TAC on this but could not find the issue.

 

Details:

Software Version8.1.9-h4

GlobalProtect Agent4.1.10

 

RoutePrint:

Active Routes:
Network Destination Netmask Gateway Interface Metric
0.0.0.0 0.0.0.0 192.168.0.1 192.168.0.199 35
0.0.0.0 0.0.0.0 On-link 10.0.0.201 50

staustin
L2 Linker

Please post a picture or details of your split tunnel configuration on your gateway.

axelrafaeltadoy
L1 Bithead

AccessroutePIC.png

axelrafaeltadoy
L1 Bithead

Please see below access route

 

AccessroutePIC.png

MickBall
L7 Applicator

default routes 0.0.0/0 always apply whether using split tunnel or not.

your more specific routes /32 /24/23 etc will take precedence over /0

 

is there any more information in your route print or have you just left it out.....

laurence64
L2 Linker

We have had a similar issue, the workaround for us was to exclude the default route from the split tunnel.

PCCSA PCNSA PCNSE
MickBall
L7 Applicator

Hmmm there must be something odd with your settings if thats the case...

I have a test gateway that only includes 10.0.0.0/8

 

route print below...

MickBall_0-1606918760207.png

 

 so any unknown traffic such as 8.8.8.8 has 2 default routes but the local interface has a lower metric (35) so no traffic goes down the tunnel unless its within 10.0.0.0/8.

 

Perhaps your metric is the other way round for some odd reason, i would only think this would happen if you had just exclude routes in your settings.

axelrafaeltadoy
L1 Bithead

We have done this but still the 0.0.0.0/0 is still there in the route print

Tags (1)
laurence64
L2 Linker

I have to agree with @MickBall the 0.0.0.0/0 route will still be in the routing table but the host will see this as a backup route, the 0.0.0.0/0 route that is via your home network gateway will be used as its metric is takes precedence over the one through the Global protect tunnel, if you were, for instance, to configure the Global Protect to tunnel all traffic then the metrics would be the other way around.

As it is your include routes are tunnelled and the host will only use the GP default route should the 192 gateway become unavailable, however that would also cut off your connectivity so you would have bigger issues!

My logic behind excluding the 0.0.0.0/0 route was simply that by actively excluding it, it may not find it's way into the routing table at all.

PCCSA PCNSA PCNSE
Like what you see?

Show your appreciation!

Click Like if a post is helpful to you or if you just want to show your support.

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!