VPN client through local PIX to remote concentrator

Unanswered Question
May 22nd, 2007

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.



I have this problem too.
0 votes
  • 1
  • 2
  • 3
  • 4
  • 5
Overall Rating: 0 (0 ratings)
pstebner1 Tue, 05/22/2007 - 12:32

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


name Inside_LAN

name LIS

name dmz

access-list outside_inbound_nat0_acl permit ip Inside_LAN

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

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

ip address inside

ip address dmz

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

nat (outside) 0 access-list outside_inbound_nat0_acl outside

nat (inside) 0 access-list 101

nat (inside) 1 Inside_LAN 0 0

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

access-group inside_access_in in interface inside

access-group dmz_in in interface dmz

route outside 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 Tue, 05/22/2007 - 12:43

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 Tue, 05/22/2007 - 12:47

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 Tue, 05/22/2007 - 15:06

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 Tue, 05/22/2007 - 19:56

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 Tue, 05/22/2007 - 20:10

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.


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 Wed, 05/23/2007 - 06:42


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.



pstebner1 Wed, 05/23/2007 - 07:09

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 Wed, 05/23/2007 - 07:23

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 Wed, 05/23/2007 - 08:20

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)



acomiskey Wed, 05/23/2007 - 08:26

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 Inside_LAN

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.

pstebner1 Wed, 05/23/2007 - 08:40

Ah, good call. I just inherited this a short time ago and hadn't noticed that...




This Discussion