VPN client through local PIX to remote concentrator

[pstebner1]

I'm sure that this has been asked before, but...

I have a VPN client behind my PIX 515E going to a remote site with a 3000 series concentrator. I can establish the tunnel, and though my client can send packets it never receives any back. I need another set of eyes or brains on this as I'm stumped. Any ACL suggestions?

Remote NAT traversal is not the problem here, btw, as the client is not NATing or PATing anything... And, I know that it's my PIX as I can connect from home.

Thanks,

Paul

[acomiskey]

Mind posting the config?

[pstebner1]

Mr. Comisky - nice to hear from you again!

Here are the relevant portions of my config:

PIX Version 6.3(4)

interface ethernet0 100full

interface ethernet1 100full

interface ethernet2 100full

nameif ethernet0 outside security0

nameif ethernet1 inside security100

nameif ethernet2 dmz security50

enable password xxxxxxxxxxxxxxx encrypted

passwd xxxxxxxxxxxxxxx encrypted

hostname ciscopix

domain-name xxxxxxxxxxxxxx

clock timezone CST -6

clock summer-time CDT recurring

fixup protocol dns maximum-length 1500

fixup protocol ftp 21

fixup protocol ftp 6055

fixup protocol h323 h225 1720

fixup protocol h323 ras 1718-1719

fixup protocol http 80

fixup protocol rsh 514

fixup protocol rtsp 554

fixup protocol sip 5060

fixup protocol sip udp 5060

fixup protocol skinny 2000

fixup protocol smtp 25

fixup protocol snmp 162

fixup protocol sqlnet 1521

fixup protocol tftp 69

names

name 192.168.20.0 Inside_LAN

name 10.0.20.100 LIS

name 10.0.20.0 dmz

access-list outside_inbound_nat0_acl permit ip 192.168.21.0 255.255.255.0 Inside_LAN 255.255.255.0

access-list inside_access_in permit ip any any

access-list inside_access_in permit udp any any

access-list inside_access_in permit tcp any any

access-list inside_access_in permit icmp any any

access-list 101 permit ip Inside_LAN 255.255.255.0 192.168.21.0 255.255.255.0

logging on

logging buffered informational

icmp permit any inside

icmp permit any dmz

mtu outside 1500

mtu inside 1500

mtu dmz 1500

ip address outside ww.xx.yyy.zzz 255.255.255.240

ip address inside 192.168.20.1 255.255.255.0

ip address dmz 10.0.20.1 255.255.255.0

ip verify reverse-path interface outside

ip audit info action alarm

ip audit attack action alarm

arp timeout 14400

global (outside) 1 interface

global (dmz) 1 10.0.20.110-10.0.20.120

nat (outside) 0 access-list outside_inbound_nat0_acl outside

nat (inside) 0 access-list 101

nat (inside) 1 Inside_LAN 255.255.255.0 0 0

static (dmz,outside) ww.xx.yyy.xzz LIS netmask 255.255.255.255 0 0

access-group inside_access_in in interface inside

access-group dmz_in in interface dmz

route outside 0.0.0.0 0.0.0.0 ww.xx.yyy.zzx 1

timeout xlate 0:30: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

floodguard enable

sysopt connection permit-ipsec

sysopt connection permit-pptp

sysopt connection permit-l2tp

sysopt noproxyarp inside

isakmp enable outside

isakmp identity address

isakmp nat-traversal 20

[acomiskey]

Nothing wrong there, might as well get rid of access-list inside_access_in as it's just permitting everything anyway. You say you are not nating or pating clients but you are pating Inside_LAN to ww.xx.yyy.zzz.

[pstebner1]

I opened up that access-list for troubleshooting purposes. Also, I am using PAT but the remote site is not, and that may or may not be where the problem lies. My VPN client is getting a class-B public address from these guys.

[acomiskey]

I assume you're also nating again on an outside router? Also, it shouldn't matter whether or not the remote end is running PAT, it is only significant that you are on the local end. Just make sure the checkbox on the concentrator is checked for NAT-T and you can rule it out as a problem.

[pstebner1]

They won't verify NAT-T is checked, but they say that they have hundreds of other clients using this VPN without issue. Also, I can get in from home and I am NATing there. It has to be something on my PIX, but I'm dumbfounded... Any other things that you can possibly think of?

[srue]

Can you check it from other PC's inside your network where you're having the issue? Can they even verify that you log in to the vpn? Also, on the 300x concentrators, they should be able to see TX/RX traffic on a per user basis. Install a sniffer on your PC and see if it verifies what you're finding.

http://www.ethereal.com

and like a previous poster stated, you can get rid of the inside access list, since you've allowed everything outbound. you're just causing more processing overhead on the PIX.

if you have a "permit ip any any", you dont need a "permit tcp/udp/icmp any any" because they all use IP, and hence those ACE's will never be matched.

--one last thought on your vpn issue, check split tunnelling. verify the address you're trying to connect to on the other end of the vpn is being transmitted through the tunnel, and not your local network.

[pstebner1]

Srue-

It is definitely a problem for all machines. Split tunneling is not being used in this case.

The access-list was a test - it is not what I would normally use.

I will try the sniffer idea - I have Ethereal on my laptop already.

Thanks,

Paul

[palomoj]

If you already verified the client is connecting and using NAT-T UDP 4500 then I would try the following:

1. clear xlate

2. reboot the PIX

3. upgrade to 6.3(5)

I have seen some funky stuff with pre 6.3(5) code that an upgrade fixed. Hopefully the clear xlate and/or reboot can fix your issue.

[owensgl]

Is the concentrator parallel to the PIX? Did you configure the default router for the concentrator and the Default gateway for the VPN traffic, which are two different configurations? Can you ping the internet from the VPN concentrator.

Greg Owens

[pstebner1]

The concentrator is at a remote client site and I have no access to it. All they will tell me is that it works for everyone else.

[acomiskey]

Add this and give it a try, if this doesnt work then nat-t is not an issue as you have suggested.

fixup protocol esp-ike

Also, what device is outside your pix?

[pstebner1]

I tried that and got:

PAT for ESP cannot be enabled since ISAKMP is enabled. Please correct your configuration and re-issue the command!

Also, my network goes switch -> PIX -> 2691 router (no access-lists except for telnet)

Thanks,

Paul

[acomiskey]

I guess it's telling you to remove isakmp nat-traversal, although I don't think this will solve you problem anyhow.

Another thing I noticed in your config is your nat exemption. You can remove the following

access-list outside_inbound_nat0_acl permit ip 192.168.21.0 255.255.255.0 Inside_LAN 255.255.255.0

nat (outside) 0 access-list outside_inbound_nat0_acl outside

This is not needed as your acl 101 is bidirectional and you are not nating on your outside interface anyway.