Route Problem

jryan · ‎03-29-2004

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

domain-name

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

names

access-list nonat permit ip 192.168.1.0 255.255.255.0 192.168.9.0 255.255.255.0

access-list nonat permit ip 172.21.1.0 255.255.255.0 192.168.9.0 255.255.255.0

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 192.168.1.11

no logging message 106011

interface ethernet0 100basetx

interface ethernet1 100basetx

mtu outside 1500

mtu inside 1500

ip address outside xx.xx.xx.xx 255.255.255.248

ip address inside 192.168.1.4 255.255.255.0

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 192.168.9.1-192.168.9.254

no pdm history enable

arp timeout 14400

global (outside) 1 interface

nat (inside) 0 access-list nonat

nat (inside) 1 0.0.0.0 0.0.0.0 0 0

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

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

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

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

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

access-group permit_in in interface outside

route outside 0.0.0.0 0.0.0.0 xx.xx.xx.xx 1

route inside 172.21.1.0 255.255.255.0 192.168.1.3 1

route inside 192.168.3.0 255.255.255.0 192.168.1.1 1

route inside 192.168.5.0 255.255.255.0 192.168.1.1 1

route inside 192.168.6.0 255.255.255.0 192.168.1.1 1

route inside 192.168.7.0 255.255.255.0 192.168.1.1 1

route inside 192.168.8.0 255.255.255.0 192.168.1.1 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 192.168.0.0 255.255.0.0 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 192.168.1.16 192.168.1.10

vpdn group 10 client configuration wins 192.168.1.10 192.168.1.16

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

scoclayton · ‎03-29-2004

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.

Scott

jryan · ‎03-29-2004

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

Report Inappropriate Content · ‎03-30-2004

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