03-29-2004 10:18 AM - edited 03-09-2019 06:54 AM
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
03-29-2004 12:08 PM
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
03-29-2004 12:39 PM
Yes it does.... thanks so much... I had the feeling i needed split-tunnelling.
03-30-2004 10:36 AM
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
Find answers to your questions by entering keywords or phrases in the Search bar above. New here? Use these resources to familiarize yourself with the community: