I have PIX501 configured for VPN at my office. I am able to connect to the office network using VPN Client version 4.0.5. Once I connect I am able to browse and use my office network resources. ONLY PROBLEM IS THAT I AM NOT ABLE TO BROWSE INTERNET USING INTERNET EXPLORER WHEN CONNECTED TO OFFICE NETWORK. As soon as I disconnect VPN Client then I am able to browse Internet. What could be the problem? Is there any configuration error?
those two commands are exactly what you need, as i don't have the ip scheme of your network.
remote vpn user (192.168.100.0/24) <--> www/vpn <--> your pix <--> your company private net (192.168.1.0/24)
remote vpn user (vpn client pool configured on pix), i.e. the ip address assigned after establishing the vpn.
to verify, you can either do "show ip local pool" on the pix or "ipconfig/all" on remote vpn user pc.
with the existing pix config, there should be sth like:
vpngroup remotevpn address-pool ippool
vpngroup remotevpn dns-server 192.168.1.100
vpngroup remotevpn idle-time 1800
vpngroup remotevpn password ********
for split tunneling configuration,
access-list split_tunnel permit ip 192.168.1.0 255.255.255.0 192.168.100.0 255.255.255.0
vpngroup remotevpn split-tunnel split_tunnel
if it doesn't make much sense, please post the config.
You need to add the following two statements to your config:
access-list split_tunnel permit ip 100.100.0.0 255.255.0.0 100.100.100.224 255.255.255.224
vpngroup compp split-tunnel split_tunnel
BTW - You are using a /16 mask on the inside interface of your pix, so I made your split-tunnel access-list match your configuration.
Make sure to disconnect the VPN client and re-connect after adding the two statements above.
Please reply back to the list if you are still having issues.
as suggested, only 2 commands are needed. however, i suggest you to modify the vpn client pool, as it is overlapping with the pix inside subnet.
imagine a host behind the pix with ip 100.100.100.151 is attempting to send a packet to a remote vpn client pc, which ip is 100.100.100.238. now, 100.100.100.151 will consider that fact that .238 is located on the lan. thus instead of sending the packet to the pix, it will send an arp request attempting to establish a connection directly. unfortunately, it will not yield any response as the remote vpn client pc is actually located somewhere else. further, if pix doesn't receive the packet, how would the pix encrypts the packet and sends across the vpn tunnel over the internet.
If you would like you can change the vpn client pool, so that it doesn't overlap with the inside interface. This would become an issue if you have hosts on the inside of the PIX 501 that overlap with ip's in the vpn client pool. That being said, this is absolutely NOT a requirement.
I have to strongly disagree with jackko as the pix will PROXY ARP for ip addresses within the ip local pool hence the packet will make it to the pix.
not too sure about the function of proxy arp, as stated from the command reference "ARP requests for any static or global address defined on the PIX Firewall interface."
nonetheless, configuring vpn client pool overlaps with the subnet behind the pix is not a good practice. imagine a user walks in with a laptop and it has a static ip that is the same ip being assigned to a remote vpn client. the administrator will waste time on troubleshooting that could be prevented by a good practice in the first place, which is, not to overlap the ip scheme.
further, address overlapping like this is not recommended by cisco. that's why you would not find a configuration example from cisco that has an overlapping ip scheme.
it's good to learn that your issue has been resolved.
according to cisco,
Why should I rate posts?
If you see a post that you think deserves recognition, please take a moment to rate it.
You'll be helping yourself and others to quickly identify useful content -- as determined by members. And you'll be ensuring that people who generously share their expertise are properly acknowledged. As posts are rated, the value of those ratings are accumulated as "points" and summarized on the Member Profile page and on each member's Preferences page.
the two statemnet basically is pushed down to the remote vpn client from the pix.
the list is then used by the remote vpn client software to determine what sort of traffic should be encrypted and sent via the vpn.
with your case, when traffic destined for the main office, the vpn client will go ahead to encrypt the packet and send down to the vpn tunnel. alternatively, if the traffic is destined for the internet (i.e. not the main office), then the vpn client will not encrypt the packet and just forward it to the internet.