Remote Cisco VPN user to PIX 501 can't get to Internet

[sitemanager]

I have a PIX 501 running the latest OS. It's working great on the LAN. I don't see any errors.

Here's the problem, there's a remote user running Windows 98 with the Cisco v4.x VPN client. Before he left, we checked his VPN connection and it seemed to be fine. We left it connected for a day. Now he's in his remote office, but he cannot get to some sites when he's using the VPN connection. I am connected at the same time as he is, and I can get to sites like "USA Today" but he cannot. When I had him ping the USA Today site, he gets an error indicating that the name cannot be found (a DNS resolution error). I also had him ping some other sites such as

http://www.cisco.com,

and while I get responses, he does not, though he does get name resolution. Since he can resolve some names, but not others, I can't determine the problem. He cannot get to many sites while the VPN connection is active.

When he disconnects the VPN, he is able to browse without issue.

Split-tunneling is enabled, and the clients have the "Allow local LAN access" checked.

His IP address on his end is not the same as any IP in use on the PIX.

I used the PDM to do all the VPN configuration, except that I had to add the line for NT tranversal.

So, I am confused because I would expect to see the same problems as him while we are both remotely connected via the VPN client.

He is in a completely different location than I, and his VPN client is v4.0.1, while mine is v4.0.3. I am running Windows XP, while he is running Windows 98.

Now here's another thing: I'm looking at the PDM log and I would expect to see *some* messages from the VPN network, but I see nothing. I am not a PIX expert, but I would think that if the log is enabled and set to 500, and I am looking at the "Notifications", I should see something from the IP range of the VPN user.

I added a couple of extra rules that probably aren't needed, too, because I am at a loss.

Any help greatly appreciated!!! He is getting *frustrated* because his work is hindered. My head hurts...

Here's the running config:

Building configuration...
: Saved
:
PIX Version 6.3(1)
interface ethernet0 auto
interface ethernet1 100full
nameif ethernet0 outside security0
nameif ethernet1 inside security100
enable password *****/********** encrypted
passwd *****/********** encrypted
hostname tollbooth
domain-name mydomain.com
clock timezone PST -8
clock summer-time PDT recurring
fixup protocol ftp 21
fixup protocol h323 h225 1720
fixup protocol h323 ras 1718-1719
fixup protocol http 80
fixup protocol ils 389
fixup protocol rsh 514
fixup protocol rtsp 554
fixup protocol sip 5060
fixup protocol sip udp 5060
fixup protocol skinny 2000
no fixup protocol smtp 25
no fixup protocol sqlnet 1521
names
access-list outside_access_in permit ip 192.168.200.0 255.255.255.0 any
access-list outside_access_in permit ip 192.168.100.0 255.255.255.0 any
access-list outside_access_in permit tcp any interface outside eq smtp
access-list outside_access_in deny tcp any interface outside eq 135
access-list outside_access_in deny udp any interface outside eq netbios-ns
access-list outside_access_in deny udp any interface outside eq netbios-dgm
access-list outside_access_in deny tcp any interface outside eq netbios-ssn
access-list outside_access_in deny tcp any interface outside eq 445
access-list inside_access_in permit ip 192.168.100.0 255.255.255.0 any
access-list inside_access_in permit ip 192.168.200.0 255.255.255.0 any
access-list inside_access_in permit ip 192.168.1.0 255.255.255.0 192.168.100.0 255.255.255.0
access-list inside_access_in permit ip 192.168.1.0 255.255.255.0 192.168.200.0 255.255.255.0
access-list inside_access_in deny tcp any any eq 135
access-list inside_access_in deny udp any any eq netbios-ns
access-list inside_access_in deny udp any any eq netbios-dgm
access-list inside_access_in deny tcp any any eq netbios-ssn
access-list inside_access_in deny tcp any any eq 445
access-list inside_access_in permit ip any any
access-list outside_cryptomap_dyn_20 permit ip any 192.168.100.0 255.255.255.0
access-list inside_cryptomap_dyn_20 permit ip any 192.168.100.0 255.255.255.0
access-list inside_outbound_nat0_acl permit ip any 192.168.100.0 255.255.255.0
access-list inside_outbound_nat0_acl permit ip any 192.168.200.0 255.255.255.0
access-list PIXvpn01_splitTunnelAcl permit ip 192.168.1.0 255.255.255.0 any
pager lines 24
logging on
logging timestamp
logging monitor notifications
logging buffered notifications
logging trap informational
no logging message 106011
icmp deny any echo-reply outside
mtu outside 1500
mtu inside 1500
ip address outside xx.xxx.xxx.137 255.255.255.0
ip address inside 192.168.1.251 255.255.255.0
ip audit info action alarm
ip audit attack action alarm
ip local pool VPNpool01 192.168.100.1-192.168.100.254
ip local pool VPNpool02 192.168.200.1-192.168.200.254
pdm location 192.168.100.0 255.255.255.0 outside
pdm location 192.168.1.0 255.255.255.0 inside
pdm location 192.168.1.2 255.255.255.255 inside
pdm location 192.168.200.0 255.255.255.0 outside
pdm location 192.168.200.0 255.255.255.0 inside
pdm location xx.xxx.xxx.22 255.255.255.255 outside
pdm logging notifications 500
pdm history enable
arp timeout 14400
global (outside) 1 interface
nat (inside) 0 access-list inside_outbound_nat0_acl
nat (inside) 1 0.0.0.0 0.0.0.0 0 0
static (inside,outside) tcp interface smtp 192.168.1.2 smtp netmask 255.255.255.255 0 0
static (inside,outside) tcp interface

http://www 192.168.1.2

http://www netmask

255.255.255.255 0 0
access-group outside_access_in in interface outside
access-group inside_access_in in interface inside
route outside 0.0.0.0 0.0.0.0 xx.xxx.xxx.114 1
timeout xlate 0:05:00
timeout conn 1:00:00 half-closed 0:10:00 udp 0:02:00 rpc 0:10:00 h225 1:00:00
timeout h323 0:05:00 mgcp 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
aaa authentication telnet console LOCAL
http server enable
http xx.xxx.xxx.22 255.255.255.255 outside
http 192.168.1.0 255.255.255.0 inside
http 192.168.100.0 255.255.255.0 inside
http 192.168.200.0 255.255.255.0 inside
no snmp-server location
no snmp-server contact
snmp-server community public
no snmp-server enable traps
floodguard enable
sysopt connection permit-ipsec
sysopt connection permit-pptp
crypto ipsec transform-set ESP-3DES-MD5 esp-3des esp-md5-hmac
crypto dynamic-map outside_dyn_map 20 set transform-set ESP-3DES-MD5
crypto dynamic-map inside_dyn_map 20 set transform-set ESP-3DES-MD5
crypto map outside_map 65535 ipsec-isakmp dynamic outside_dyn_map
crypto map outside_map interface outside
crypto map inside_map 65535 ipsec-isakmp dynamic inside_dyn_map
crypto map inside_map interface inside
isakmp enable outside
isakmp nat-traversal 20
isakmp policy 20 authentication pre-share
isakmp policy 20 encryption 3des
isakmp policy 20 hash md5
isakmp policy 20 group 2
isakmp policy 20 lifetime 86400
vpngroup PIXvpn01 address-pool VPNpool01
vpngroup PIXvpn01 dns-server yy.yyy.yyy.5 24.221.162.5
vpngroup PIXvpn01 wins-server 192.168.1.2 192.168.1.2
vpngroup PIXvpn01 default-domain mydomain.com
vpngroup PIXvpn01 split-tunnel PIXvpn01_splitTunnelAcl
vpngroup PIXvpn01 idle-time 1800
vpngroup PIXvpn01 password ********
telnet 192.168.1.0 255.255.255.0 inside
telnet 192.168.100.0 255.255.255.0 inside
telnet 192.168.200.0 255.255.255.0 inside
telnet timeout 5
ssh 192.168.1.0 255.255.255.0 inside
ssh 192.168.100.0 255.255.255.0 inside
ssh 192.168.200.0 255.255.255.0 inside
ssh timeout 5
management-access inside
console timeout 30
vpdn group PPTP-VPDN-GROUP accept dialin pptp
vpdn group PPTP-VPDN-GROUP ppp authentication chap
vpdn group PPTP-VPDN-GROUP ppp authentication mschap
vpdn group PPTP-VPDN-GROUP ppp encryption mppe auto
vpdn group PPTP-VPDN-GROUP client configuration address local VPNpool02
vpdn group PPTP-VPDN-GROUP client configuration dns yy.yyy.yyy.5 yy.yyy.zzz.5
vpdn group PPTP-VPDN-GROUP client configuration wins 192.168.1.2 192.168.1.2
vpdn group PPTP-VPDN-GROUP pptp echo 60
vpdn group PPTP-VPDN-GROUP client authentication local
vpdn username user3 password *********
vpdn username user1 password *********
vpdn enable outside
dhcpd address 192.168.1.252-192.168.1.254 inside
dhcpd lease 3600
dhcpd ping_timeout 750
dhcpd auto_config outside
username user1 password xxxxxx encrypted privilege 15
username monitor nopassword privilege 3
username user2 password xxxxxx/JM.JO encrypted privilege 15
username user3 password xxxxxx encrypted privilege 15
terminal width 80
banner login Authorized users only!!
Cryptochecksum:xxxxxxxxxxxxxxxxxxxxxxxx
: end
[OK]



Thanks!!!!

 

[bierhunter]

First I'd recommend him upgrading to v4.0.3C or newer. That version fixes a lot of problems. One of them being strange vpn routing issues.

You have split tunnel, so that's good. I usually set up our clients to use their own ISP for regular internet traffic and the vpn for company related stuff.

One thing I've always done is to never use a 192.168.x.x subnet for anything network related at the company. Mainly because most home/small office type routers use that range and it can possibly cause confusion with vpns if you end up connecting to a remote lan with the same subnet.

 

[sitemanager]

bierhunter,

Thanks for the quick response. I was starting to wonder the same thing about the client. I am sending hime the 4.0.3 version to see if that fixes his probkem.

I'll update the thread after he gets back to me.

-- Rob --

 

[sitemanager]

I've had the guy update his client to v4.0.3 (C) which is the same as I am running.


Some interesting things:

1) On my client and his, even though we have "Local LAN" checked for our connection entry, the statistics when connected show "Local LAN: disabled".

2) After he logs onto the NT domain, the little lock icon seems to disappear. (According to him, it's there and then it disappears.) He clicked in the area of where it should be and the options menu pops up. I'm not sure what, exactly, he is seeing.

3) He's got WIndows 98 and the WINIPCFG /ALL command just pops up the WINIPCFG window.

4) There is no firewall on his end. He can browse sites with the IP addresses, but they don't really work with the domain names when he's using the VPN. I can browse any site with no problems while using the VPN.

5) He's connected to the VPN right now and so am I. In the PDM, under monitoring, reading the VPN statistics, under IPsec VPNs, is the following peer information:
mine is x1.x2.x3.x4:4500
his is y1.y2.y3.y4:500

Why the different port numbers??


I called the remote site tech support person and he said there are no ports being blocked on their router (that he is aware of). Since there's no firewall, I can't see that they would be dropping DNS packets.

Since the remote user is using Windows 98 and I am using Windows XP, I am further confused.

AHHHHHHHHH!!!


-- Rob --

 

[chicocouk]

Well your split tunneling ACL is off for a start, it should be as follows;

access-list PIXvpn01_splitTunnelAcl permit ip 192.168.1.0 255.255.255.0 192.168.100.0 255.255.255.0

Also, what DNS servers are you handing out in your
"vpngroup PIXvpn01 dns-server yy.yyy.yyy.5 24.221.162.5" command? Are they both public DNS servers? If so, why are you handing them out? The client already presumably has public dns servers, since it can browse the net before you connect the vpn, but I think you're giving it some more. You should hand out the ip addresses of LOCAL dns servers on your 192.168.1.0 network range if the client needs to resolve the names of machines on that network.

Further, you might want to add the following command to your config;

vpngroup PIXvpn01 split-dns mydomain.com

Where "mydomain.com" is whatever you've already specified in your vpngroup commands, so you only route traffic to those local dns servers that is traffic that should be dealt with by those local dns servers.

Lastly, that's the local ip range used by the 9x machine, and what does it use for dns servers in it's local area network connections settings?

If either of them are on the 192.168.1.0/24 range you use at your main site, then it will have trouble resolving dns, as that traffic will be routed up your IpSec tunnel.

Imagine your 9x client uses 192.168.1.1 as it's dns server (possibly it's local router). But you then create a vpn and say, route all traffic for 192.168.1.0/24 over a vpn to our main site. And then at the main site you don't have a dns server sitting at 192.168.1.1

Sorry this is a bit rushed, hope it's some help

Chico


CCNA, MCSE, Cisco Firewall specialist, VPN specialist, wannabe CCSP

 

[sitemanager]

Chico,

Thanks for the help!

Keep in mind that most settings were created by the PDM.

Going in order,

1) The PDM set this. Why is the original split-tunnel command wrong? I mean, you are changing "any" to a specific range. The specific range is a sub-set of "any", so I'm curious why you'd change it.

2) As for the "vpngroup PIXvpn01 dns-server" command, the DNS entries are created by the PDM. I had assumed that the PDM added these entries because, if you didn't use split-tunneling, you would need DNS servers to resolve names on the Internet. Later, of course, I discovered that a PIX is not capable of allowing VPN traffic back, as do other firewalls. So, I'm assuming I can remove this command line, then.

3) So, would I still need the split-DNS command if I remove the "vpngroup PIXvpn01 dns-server" command? Or, do I still need the split-DNS to resolve external hosts while using the split-tunneling? I was also assuming that selecting the "Local LAN" option on the Cisco VPN client would allow the use of local Internet access while using the VPN. Again, I am confused regarding the PIX.

4) His remote IP address (network) is completely different. He has a public IP on his client and local (to him) DNS entries.

I did some checking on the PDM and I was concerned when I saw his IP was using port 500 and mine was using port 4500 (on the IPsec VPN statistics).

I am concerned that the "Local LAN" setting on the client does nothing.

I am also concerned that with all the same PIX settings, my Windows XP system works fine, while his Windows 98 system does not.


Thanks again for your help. Sorry for all my questions, but I really want to understand this. Maybe it's just his system.

Thanks!

-- Rob --

 

[chicocouk]

Okay, let's try to make sense of this

1) Yes, PDM set this. But you provided PDM with the details, didn't you? PDM didn't just make them up itself, it has a wizard, and you filled in the required fields. Go through the remote access wizard again, and you should spot the page where you specify this. As to why you would want to be more granular, well the simple fact is that you DON'T want to send all traffic down the vpn. You only want traffic that originates from your local ip range on the client, and is destined for the local ip range of the network behind the PIX. A better question to ask would be why would you WANT to allow any other traffic down the vpn? Answer - you wouldn't.

2) No, the dns entries were not created by the PDM. PDM has a wizard that asks if you want to push dns server information or not. You filled that in with DNS servers. But you don't *NEED* to. PDM won't force you to. And you don't need to push public dns servers to the client in this situation.

3) If your vpn client machines need to resolve the names of any machines at your main site, you will need to provide it with the ip addresses of DNS servers at the main site which hold that information. The Split-DNS command then tunnels only DNS requests that are for your hosts which end with your "default-domain" suffix to those DNS servers. All others will go to the clients "normal" DNS servers, the ones it uses when VPN is not connected.

4) The fact that the DNS servers your client uses are local to him is interesting, as it appears that local access does not work properly for you. So the client can't contact those local DNS servers to resolve hosts, and can presumably only resolve hosts it has already cached. I would be interested to know whether the ACL change i've suggested will resolve that issue for you.

The XP versus 98 is a red herring, I don't believe it's relevant at all. I do believe your differing network ranges etc are relevant. Ie, your XP machine is behind a NAT device, your 98 machine isn't. That's why the 98 machine is registering on UDP port 500 (used for IKE Phase 1 proposals), whereas your XP machine is registering as UDP port 4500 (used when clients have to use Nat-Traversal, because they are behind a NAT device.)

I am very interested in getting to the bottom of this, as the Local LAN access tickbox doesn't work as you would expect when used with the vpn client and a pix, you can't just tick it and it work, and I'd like to get clear how to properly use it. I believe properly configuring split-tunnelling resolves it, but i'd like to see that demonstrated.

As a quick workaround, if you need to get this sorted fast, you could give the 98 machine DNS servers that *aren't* local to it, eg 195.92.195.92 and 195.92.195.93. Note that you would make those changes in local area connections on the 98 machine, not in the pix config.

Best of luck!

Chico



CCNA, MCSE, Cisco Firewall specialist, VPN specialist, wannabe CCSP

 

[sitemanager]

Chico,

Thanks for all your time.

I'll just address a couple of things, since most of what you said was really helpful.

And just a comment on the PDM wizard: if it's there, and there's no help, most people are going to enter the "requested" data, as I did. That's Cisco's fault for poor documentation, and my fault for not spending $3000 on training. I had the definition of split-DNS, but I didn't know if the vpngroup setup needed those DNS entries. I'll remove those entries.

On point 4) and your last paragraph, he actually had the DNS entries from his office (before he moved), and he was able to resolve names without the VPN connection after he moved to different area. When he used the VPN, name resolution became a problem. I had him change his DNS entries to DNS servers on his remote network (where he is currently located), and he was still able to resolve any names when he wasn't on the VPN. When he used the VPN, name resolution seemed to start failing.

Without having a sniffer, my testing leads me to believe the some portion of the DNS traffic is getting dropped while the VPN is in use. Without being able to test the client directly, I can't do very good testing. (He's always busy or he needs to leave.)

The explanation of the port usage of the clients is really good to know. Thanks!

Since I don't know what else to change on the PIX, I guess my only other question is, how can I determine if packets are being dropped using the PDM or a telnet session? I tried doing what seemed obvious, but I'm not seeing anything significant. I don't know how to properly debug his session.

Thank you, thank you!!

-- Rob --

 

[chicocouk]

Rob,

I didn't mean at all to sound critical of you using the PDM wizard, or anything along those lines, if my post came across that way it was more down to tiredness on my part rather than intention. For the most part I'm quite a fan of PDM, it does a decent job of doing what it's supposed to do, and for some configuration changes (eg grouping hosts into logical groups and assigning different acls to them etc), it can be a LOT faster and more practical than the command line (especially on the bigger, busier PIX). My post sounds a bit aggressive, so I apologise, I didn't mean it that way.

It's interesting that he had trouble resolving DNS using servers that were local to him and also using ones that weren't local to him when connected to the vpn. That would seem to blow my theory out of the water ... especially if he can ping his "normal" (local area connection) dns servers while his vpn client is active. If he can, then he can route traffic to them. If he can't, then something is wrong, and you might want to experiment with different dns servers. Easiest way would be to get a few to try before contacting him, and see if he can ping any of them when the vpn client is up.

If you do narrow it down to it being an issue with dns traffic specifically (port 53), you could run a packet sniffer on the PIX, using the debug packet trace command, looking specifically for dns traffic originating from that host. You may be able to establish that dns traffic is being routed down the vpn for some reason (although I can't see anything in your config that looks like that should happen, it can't hurt to try)

debug packet trace documentation is here:

http://www.cisco.com/univercd/cc/td/doc/product/iaabu/pix/pix_62/cmdref/df.htm#1059143

I'm getting more curious about this all the time, hope we can figure it out



CCNA, MCSE, Cisco Firewall specialist, VPN specialist, wannabe CCSP

 

[sitemanager]

Hey, no problem. I appreciate the help, and I HATE the PDM!! Not being a PIX expert forces me to use it.

I'm really frustrated with this, and the guy I'm trying to help is going to have to bring someone else in because I can't resolve the issue.

I'm also try to get an understanding here for people that may seach and find this thread. (That's how I discovered Tek-Tips, myself.) Some threads aren't detailed enough.

I wish the PIX had GUI-based logging displays like on a SonicWall, NetGear, LinkSys, et al, where you can just view the basic traffic that is passing or denied. It is so much easier to find problems.

As for the debugging, I know what the commands are, but they seem to do nothing. I have telnet and PDM access. If I set "debug dns all", I see nothing different. Nothing shows up in the telnet session or the PDM logs that I am looking at. As for the PDM logs, I have looked at the Notifications, Warnings and Errors.

----
So, I just got off the phone with him, and the good news is that his browsing seems to be working now!!

The bad news is that I'm not sure which setting made a difference. I'll go with the adjusted split-tunneling command.

It still seems as though data is getting blocked. I tried to initiate a Remote Administrator session to his system from a server on the LAN (behind the PIX), and it failed. Also, it seems like no debug commands are working for DNS tracking, though there is probably some other setting I am missing.

I would think if I telnet into the PIX, do a "debug dns all", then I should see some data. The PDM notifications log shows nothing of DNS.

My only remaining question is why is there a "Local LAN" checkbox on the client? Is it used for anything?



This has become a long thread. I hope it helps someone else sometime. I'll make one last post after he calls tomorrow.

Thanks VERY much for all your help and time!!!!

-- Rob --

 

[sitemanager]

Actually, while sending an update to another forum, I realize the problem could most likely have been the unneccessary "vpngroup PIXvpn01 dns-server yyy.yyy.141.1 yyy.yyy.142.1" command, which I removed per Chico's suggestion.

The combination of that and the adjusted split-tunnel command must have done the trick.

Thanks, Chico!!


Just in case anyone searches and finds this thread helpful, here's my current config:

Building configuration...
: Saved
:
PIX Version 6.3(1)
interface ethernet0 auto
interface ethernet1 100full
nameif ethernet0 outside security0
nameif ethernet1 inside security100
enable password ********** encrypted
passwd ********** encrypted
hostname tollbooth
domain-name mydomain.com
clock timezone PST -8
clock summer-time PDT recurring
fixup protocol ftp 21
fixup protocol h323 h225 1720
fixup protocol h323 ras 1718-1719
fixup protocol http 80
fixup protocol ils 389
fixup protocol rsh 514
fixup protocol rtsp 554
fixup protocol sip 5060
fixup protocol sip udp 5060
fixup protocol skinny 2000
no fixup protocol smtp 25
no fixup protocol sqlnet 1521
names
access-list outside_access_in permit ip 192.168.200.0 255.255.255.0 any
access-list outside_access_in permit ip 192.168.100.0 255.255.255.0 any
access-list outside_access_in permit tcp any interface outside eq smtp
access-list outside_access_in deny tcp any interface outside eq 135
access-list outside_access_in deny udp any interface outside eq netbios-ns
access-list outside_access_in deny udp any interface outside eq netbios-dgm
access-list outside_access_in deny tcp any interface outside eq netbios-ssn
access-list outside_access_in deny tcp any interface outside eq 445
access-list inside_access_in permit ip 192.168.100.0 255.255.255.0 any
access-list inside_access_in permit ip 192.168.200.0 255.255.255.0 any
access-list inside_access_in permit ip 192.168.1.0 255.255.255.0 192.168.100.0 255.255.255.0
access-list inside_access_in permit ip 192.168.1.0 255.255.255.0 192.168.200.0 255.255.255.0
access-list inside_access_in deny tcp any any eq 135
access-list inside_access_in deny udp any any eq netbios-ns
access-list inside_access_in deny udp any any eq netbios-dgm
access-list inside_access_in deny tcp any any eq netbios-ssn
access-list inside_access_in deny tcp any any eq 445
access-list inside_access_in permit ip any any
access-list outside_cryptomap_dyn_20 permit ip any 192.168.100.0 255.255.255.0
access-list inside_cryptomap_dyn_20 permit ip any 192.168.100.0 255.255.255.0
access-list inside_outbound_nat0_acl permit ip any 192.168.100.0 255.255.255.0
access-list inside_outbound_nat0_acl permit ip any 192.168.200.0 255.255.255.0
access-list PIXvpn01_splitTunnelAcl permit ip 192.168.1.0 255.255.255.0 192.168.100.0 255.255.255.0
pager lines 24
logging on
logging timestamp
logging monitor informational
logging trap informational
no logging message 106011
icmp deny any echo-reply outside
mtu outside 1500
mtu inside 1500
ip address outside xxx.xxx.182.137 255.255.255.0
ip address inside 192.168.1.251 255.255.255.0
ip audit info action alarm
ip audit attack action alarm
ip local pool VPNpool01 192.168.100.1-192.168.100.254
ip local pool VPNpool02 192.168.200.1-192.168.200.254
pdm location 192.168.100.0 255.255.255.0 outside
pdm location 192.168.1.0 255.255.255.0 inside
pdm location 192.168.1.2 255.255.255.255 inside
pdm location 192.168.200.0 255.255.255.0 outside
pdm location 192.168.200.0 255.255.255.0 inside
pdm location xxx.xxx.182.22 255.255.255.255 outside
pdm logging informational 512
pdm history enable
arp timeout 14400
global (outside) 1 interface
nat (inside) 0 access-list inside_outbound_nat0_acl
nat (inside) 1 0.0.0.0 0.0.0.0 0 0
static (inside,outside) tcp interface smtp 192.168.1.2 smtp netmask 255.255.255.255 0 0
static (inside,outside) tcp interface

http://www 192.168.1.2

http://www netmask

255.255.255.255 0 0
access-group outside_access_in in interface outside
access-group inside_access_in in interface inside
route outside 0.0.0.0 0.0.0.0 xxx.xxx.182.114 1
timeout xlate 0:05:00
timeout conn 1:00:00 half-closed 0:10:00 udp 0:02:00 rpc 0:10:00 h225 1:00:00
timeout h323 0:05:00 mgcp 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
aaa authentication telnet console LOCAL
http server enable
http 192.168.1.0 255.255.255.0 inside
http 192.168.100.0 255.255.255.0 inside
http 192.168.200.0 255.255.255.0 inside
no snmp-server location
no snmp-server contact
snmp-server community public
no snmp-server enable traps
floodguard enable
sysopt connection permit-ipsec
sysopt connection permit-pptp
crypto ipsec transform-set ESP-3DES-MD5 esp-3des esp-md5-hmac
crypto dynamic-map outside_dyn_map 20 set transform-set ESP-3DES-MD5
crypto dynamic-map inside_dyn_map 20 set transform-set ESP-3DES-MD5
crypto map outside_map 65535 ipsec-isakmp dynamic outside_dyn_map
crypto map outside_map interface outside
crypto map inside_map 65535 ipsec-isakmp dynamic inside_dyn_map
crypto map inside_map interface inside
isakmp enable outside
isakmp nat-traversal 20
isakmp policy 20 authentication pre-share
isakmp policy 20 encryption 3des
isakmp policy 20 hash md5
isakmp policy 20 group 2
isakmp policy 20 lifetime 86400
vpngroup PIXvpn01 address-pool VPNpool01
vpngroup PIXvpn01 wins-server 192.168.1.2 192.168.1.2
vpngroup PIXvpn01 default-domain mydomain.com
vpngroup PIXvpn01 split-tunnel PIXvpn01_splitTunnelAcl
vpngroup PIXvpn01 idle-time 1800
vpngroup PIXvpn01 password ********
telnet 192.168.1.0 255.255.255.0 inside
telnet 192.168.100.0 255.255.255.0 inside
telnet 192.168.200.0 255.255.255.0 inside
telnet timeout 15
ssh 192.168.1.0 255.255.255.0 inside
ssh 192.168.100.0 255.255.255.0 inside
ssh 192.168.200.0 255.255.255.0 inside
ssh timeout 5
management-access inside
console timeout 30
vpdn group PPTP-VPDN-GROUP accept dialin pptp
vpdn group PPTP-VPDN-GROUP ppp authentication chap
vpdn group PPTP-VPDN-GROUP ppp authentication mschap
vpdn group PPTP-VPDN-GROUP ppp encryption mppe auto
vpdn group PPTP-VPDN-GROUP client configuration address local VPNpool02
vpdn group PPTP-VPDN-GROUP client configuration dns xxx.xxx.161.5 xxx.xxx.162.5
vpdn group PPTP-VPDN-GROUP client configuration wins 192.168.1.2 192.168.1.2
vpdn group PPTP-VPDN-GROUP pptp echo 60
vpdn group PPTP-VPDN-GROUP client authentication local
vpdn username user1 password *********
vpdn username user2 password *********
vpdn enable outside
dhcpd address 192.168.1.252-192.168.1.254 inside
dhcpd lease 3600
dhcpd ping_timeout 750
dhcpd auto_config outside
username user2 password *********** encrypted privilege 15
username user3 password *********** encrypted privilege 15
username user1 password *********** encrypted privilege 15
terminal width 80
banner login Authorized users only!!
Cryptochecksum:********************************
: end
[OK]

 

[chicocouk]

Rob,

Glad we've got there, even if we've not totally nailed down what the problem was. Regarding the tick box in the vpn client, bear in mind that the vpn client can be used to connect to cisco vpn concentrators, vpn aware routers etc as well as the pix.

If i remember right, when connected to the concentrator the local lan access box does work as you'd imagine. When connected to the pix, it doesn't work as you would expect it to. I seem to remember this is because priority is given to the config the pix pushes to the client. So if the pix is pushing a config that doesn't allow split tunneling, local lan access gets barred, because the pix is authoritative. I believe the concentrators allow you to choose from the client end, rather than having it pushed down to you. I *think* you can define that as a policy on the concentrators, so client users can decide, or you can lock them to having local lan access or not, as you like.

As for you not being able to get remote admin session to him, remember that the vpn client installs a modified version of Zone Alarm, so even if he didn't have a firewall installed before you gave him the cisco vpn client, he does now.

If you need to get past this, get him to right click the "lock" icon in his system tray, and un-tick "Stateful Firewall (always on)". It defaults to off when installed, but he may have turned it on.

All the best

CCNA, MCSE, Cisco Firewall specialist, VPN specialist, wannabe CCSP