Problem VPN Split-Tunneling

cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 
Announcements
Please sign in to see details of an important advisory in our Customer Advisories area.

Problem VPN Split-Tunneling

L2 Linker

Hi everybody.

I've got a strange problem related to split tunneling in PAN configuration. The situation is:

- Portal and Gateway configuration in PAN-2050 with PANOS 4.1.7 (same results with 4.1.6 and 4.1.5).

- VPN client Cisco compatible (Windows and Linux, same results)

- IP Pool: 192.168.46.0/24

- Access routes: 10.0.0.0/8 and 172.16.0.0/12

The problem is the following one (X.X.X.X is the public ip address of the VPN gateway):

- If I configure one access route, 10.0.0.0/8, it works well, the client routing table is correct and I have connectivity through the tunnel:

root@vangogh:/home/juan# route -n

Kernel IP routing table

Destination     Gateway         Genmask         Flags Metric Ref    Use Iface

192.168.46.1    0.0.0.0         255.255.255.255 UH    0      0        0 tun0

X.X.X.X   192.168.1.1     255.255.255.255 UGH   0      0        0 wlan0

192.168.1.0     0.0.0.0         255.255.255.0   U     0      0        0 wlan0

10.0.0.0      0.0.0.0         255.0.0.0     U     0      0        0 tun0

0.0.0.0         192.168.1.1     0.0.0.0         UG    0      0        0 wlan0

root@vangogh:/home/juan#

- If I configure one access route, 172.16.0.0/12, it works well, the client routing table is correct and I have connectivity through the tunnel:

root@vangogh:/home/juan# route -n

Kernel IP routing table

Destination     Gateway         Genmask         Flags Metric Ref    Use Iface

192.168.46.1    0.0.0.0         255.255.255.255 UH    0      0        0 tun0

X.X.X.X   192.168.1.1     255.255.255.255 UGH   0      0        0 wlan0

192.168.1.0     0.0.0.0         255.255.255.0   U     0      0        0 wlan0

172.16.0.0      0.0.0.0         255.240.0.0     U     0      0        0 tun0

0.0.0.0         192.168.1.1     0.0.0.0         UG    0      0        0 wlan0

root@vangogh:/home/juan#

- But if I configure both access routes (desired configuration), it seems that the VPN client "summarize" both access routes and create a kind of default route, losing Internet connection:

root@vangogh:/home/juan# route -n

Kernel IP routing table

Destination     Gateway         Genmask         Flags Metric Ref    Use Iface

192.168.46.1    0.0.0.0         255.255.255.255 UH    0      0        0 tun0

X.X.X.X   192.168.1.1     255.255.255.255 UGH   0      0        0 wlan0

192.168.1.0     0.0.0.0         255.255.255.0   U     0      0        0 wlan0

0.0.0.0         0.0.0.0         0.0.0.0         U     0      0        0 tun0

root@vangogh:/home/juan#

Any ideas? Any similar problems?

Thank you very much.

1 accepted solution

Accepted Solutions

L5 Sessionator

We support only GP client with Windows and MAC OS. We do not officially support the Cisco VPN Client.

View solution in original post

14 REPLIES 14

L0 Member

I have a similar problem with PANOS 4.1.6 and 4.1.7 , but also with only one access-route. It summarize in a strange manner.  If I specify an access-route like 192.168.11.0/24 it summarize like 192.0.0.0/254.0.0.0, but if I specify an access-route like 172.16.0.0/12 it summarize like 128.0.0.0/128.0.0.0, if I specify an access-route like 10.0.0.0/8 it summarize like 0.0.0.0/0.

L5 Sessionator

Hello,

I have a similar setup in lab where I am allowing two networks through access routes and my routes are NOT being summarized:

100.1.1.0    255.255.255.0      10.16.0.252     10.16.0.252       1

100.1.2.0    255.255.255.0      10.16.0.252     10.16.0.252       1

Access routes are only summarized on iOS devices and should be listed as individual networks on Windows/Linux machines. Please open a Support case so that we can further look into the issue.

Thanks,

Sri

L2 Linker

Hi everybody.

Sri, I've configured our firewall with your two access routes: 100.1.1.0/24 and 100.1.2.0/24 and this is the client routing table:

IPv4 Tabla de enrutamiento

===========================================================================

Rutas activas:

Destino de red        Máscara de red   Puerta de enlace   Interfaz  Métrica

          0.0.0.0          0.0.0.0              192.168.1.5     192.168.1.20     25

        100.1.0.0    255.255.252.0     192.168.46.3     192.168.46.2    100

As you can see, it summarizes the routes. I'm using Cisco VPN Client version 5.0.

Please, could you tell me your configuration? I'll try to open a case.

Thank you very much.

Hello,

in my lab with a PAN2020 and PANOS 4.1.7, I have inserted two access-route like yours,

FireShot Screen Capture #011 -

but in my Cisco VPN client v. 5.0.0.7 on Windows XP, secured routes shows this

CiscoClient.png

If I insert only one access-route like 192.168.11.0/24, secured routes shows 192.0.0.0 254.0.0.0

Thanks,

Lauro

L2 Linker

Thanks Lauro. It is very strange behavior. Let's see if together we can find the solution.

Hello,

I have done some tests in my lab and my idea is following:

  • it depends by insertion of primary/secondary DNS and the combination of access routes
  • the system tries to summarize the networks from the DNS, if present, and the access routes inserted. If exists a super network that summarizes all, than this network is tunneled, otherwise the split-tunnel is 0.0.0.0/0
  • my opinion is that is not correct, because I should have the possibility to split single networks and single DNS. In my routing table I should have all the single networks that I specified in access routes (in the help row below the panel configuration is written "These routes will be added to the client's routing table"  plural: these routes Smiley Wink  )


Thanks.

Lauro

L2 Linker

Hi Lauro.

You're right. I've carried out some tests by changing DNS configuration in GlobalProtect Gateway. As you say, it tries to summarize all the networks: DNS networks and access routes networks........ what a folly!!!

It'd be a good idea that Sri could specify here his GlobalProtect configuration.

Thank you.

Hello,

I am using GP client 1.1.5. I have not tested this with a Cisco VPN client.

Thanks,

Sri

L2 Linker

Hello Sri.

I've tested this with a Cisco VPN client in a Windows machine, Cisco VPN Client in a Linux Machine, vpnc daemon in a Linux Machine, Shrew software in a Linux machine and Shrew software in a Windows Machine, with the same result....

Is it a compatibility problem of PaloAlto devices? I think IPSec connections are based on a RFC standard..............

Thank you very much...

L1 Bithead

We are using 2 injected routes - they were summarized to network 128.0.0.0 128.0.0.0 :-).

Workaround  - in the vpnc we have  configured to ignore routes sent by PA, and manually added routes (without setting default route (only net/mask)).

And it works 🙂

I think the same option is possible in Shrew client

L5 Sessionator

We support only GP client with Windows and MAC OS. We do not officially support the Cisco VPN Client.

L2 Linker

Hi.

Thank you Jacek. Finally I've created a shell script using vpnc command to connect and add the routes. It works.

In my opinion, PaloAlto should offer a solution for GlobalProtect VPN on Linux platforms, in case they want to take advantage over their competitors.

Bye!

Hello Jacek,

Have you tried testing VPNC client against Cisco 2900s vpn ? Do you need to manually add routes to VPNC client for split tunneling to work ? or it was just needed while using VPNC clients against PAN FWs ?

Thanks!!

  • 1 accepted solution
  • 6721 Views
  • 14 replies
  • 0 Likes
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!