Cisco Support Community
Showing results for 
Search instead for 
Did you mean: 
Community Member

Route Problem

I have a PIX 515 and use it for VPN connection. When someone connects to the network via VPN it assigns them an internet network address. The problem is that when they vpn still need access to the internet to get to some sites. They are unable to get to any. Why?

PIX Version 6.2(2)

nameif ethernet0 outside security0

nameif ethernet1 inside security100

hostname Zeus


clock timezone EST -5

clock summer-time EDT recurring

fixup protocol ftp 21

fixup protocol http 80

fixup protocol h323 h225 1720

fixup protocol h323 ras 1718-1719

fixup protocol ils 389

fixup protocol rsh 514

fixup protocol rtsp 554

fixup protocol smtp 25

fixup protocol sqlnet 1521

fixup protocol sip 5060

fixup protocol skinny 2000


access-list nonat permit ip

access-list nonat permit ip

access-list permit_in permit tcp any host xx.xx.xx.xx eq www

access-list permit_in permit tcp any host xx.xx.xx.xx eq https

access-list permit_in permit tcp any host xx.xx.xx.xx eq smtp

access-list permit_in permit tcp any host xx.xx.xx.xx eq pcanywhere-data

access-list permit_in permit udp any host xx.xx.xx.xx eq pcanywhere-status

pager lines 24

logging on

logging timestamp

logging trap warnings

logging host inside

no logging message 106011

interface ethernet0 100basetx

interface ethernet1 100basetx

mtu outside 1500

mtu inside 1500

ip address outside xx.xx.xx.xx

ip address inside

ip verify reverse-path interface outside

ip verify reverse-path interface inside

ip audit info action alarm

ip audit attack action alarm

ip local pool cccupool

no pdm history enable

arp timeout 14400

global (outside) 1 interface

nat (inside) 0 access-list nonat

nat (inside) 1 0 0

static (inside,outside) tcp xx.xx.xx.xx www www netmask 0 0

static (inside,outside) tcp xx.xx.xx.xx https https netmask 0 0

static (inside,outside) tcp xx.xx.xx.xx smtp smtp netmask 0 0

static (inside,outside) tcp xx.xx.xx.xx pcanywhere-data pcanywhere-data netmask 0 0

static (inside,outside) udp xx.xx.xx.xx pcanywhere-status pcanywhere-status netmask 0 0

access-group permit_in in interface outside

route outside xx.xx.xx.xx 1

route inside 1

route inside 1

route inside 1

route inside 1

route inside 1

route inside 1

timeout xlate 3:00:00

timeout conn 1:00:00 half-closed 0:10:00 udp 0:02:00 rpc 0:10:00 h323 0:05:00 sip 0:30:00 sip_media 0:02:00

timeout uauth 0:05:00 absolute

aaa-server TACACS+ protocol tacacs+

aaa-server RADIUS protocol radius

aaa-server LOCAL protocol local

no snmp-server location

no snmp-server contact

no snmp-server enable traps

floodguard enable

sysopt security fragguard

sysopt connection permit-ipsec

sysopt connection permit-pptp

no sysopt route dnat

telnet inside

telnet timeout 5

ssh timeout 5

vpdn group 10 accept dialin pptp

vpdn group 10 ppp authentication chap

vpdn group 10 ppp authentication mschap

vpdn group 10 ppp encryption mppe 128 required

vpdn group 10 client configuration address local cccupool

vpdn group 10 client configuration dns

vpdn group 10 client configuration wins

vpdn group 10 pptp echo 60

vpdn group 10 client authentication local

vpdn username j password ********

vpdn username n password ********

vpdn enable outside

terminal width 80


Re: Route Problem

The reason for this is because the PIX does not redirect packets back out the same interface where they were received. In this case, you are receiving PPTP traffic on the outside interface and then asking the PIX to decrypt the traffic and send it back out the outside interface to the Internet. Packets need to come in one interface and leave another interface in order to be allowed.

As for a solution, IPSec has a feature known as split-tunnelling. This allows an IPSec client to encrypt only the traffic destined to the internal network. The remainder of the traffic is unencrypted and sent out the normal ISP links. In your case, however, you are using PPTP for your VPN connections. PPTP does not have this ability. So, the work-arounds in your case are to either move all of your VPN clients to an IPSec client or bring your PPTP tunnels in a seperate interface on the PIX and send them out to the Internet via the existing outside interface (though this last solution can get tricky from a routing stand-point).

Sorry for the problems but I hope this helps to explain.


Community Member

Re: Route Problem

Yes it does.... thanks so much... I had the feeling i needed split-tunnelling.


Re: Route Problem

jryan, I had a simular problem with my pix515 and clients dropping the local network. I had to add a tunnel split command as follows: "vpngroup [groupname] split-tunnel split" However I think there is some difference in your command verbage then mine. Not sure as too why, but all my groups read as: "vpngroup [groupname] [command]" maybe cause mine is set up for individual logins and not a group as i think yours are.

hope this helps, jliljenberg

CreatePlease to create content