vpn 3005 on pix515 dmz not working

[waifurchin]

I am trying to authenticate to a vpn 3005 sitting on a pix 515 dmz. The 3005 is using the internal auth server (it's own), and is not using certificates.

This is not a live setup so there is no edge router, and no lan connection. Just a laptop, a pix, and a 3005.

If I plug the laptop into the 3005 directly the Cisco client authenticates easily using nat/udp, or plain udp.

If I stick the pix in the middle, the client just times out regardless of what nat setting I try. Currently I was trying to use nat/tcp on port 10000. The hitcnt on the acl for tcp 10000 increments, but the authentication box never pops up.

Please advise. I am indifferent to nat/tcp vs nat/udp as long as one works and clients behind a firewall can connect once it goes live.

Current config:

PIX Version 6.3(3)

interface ethernet0 auto

interface ethernet1 auto

interface ethernet2 auto

nameif ethernet0 outside security0

nameif ethernet1 inside security100

nameif ethernet2 dmz security10

hostname Pix515

fixup protocol dns maximum-length 512

fixup protocol ftp 21

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 sqlnet 1521

fixup protocol tftp 69

names

name a.b.c.1 router

name a.b.c.3 vpn_ext

name 192.168.0.1 vpn_dmz

name 192.168.1.254 pix_lan

name 192.168.0.254 pix_dmz

name a.b.c.254 pix_ext

name 192.168.0.0 all_dmz

name 192.168.1.0 all_lan

access-list out permit tcp any host vpn_ext eq 10000

access-list dmz permit ip all_lan 255.255.255.0 all_dmz 255.255.255.0

pager lines 24

logging on

logging timestamp

logging buffered warnings

logging trap warnings

logging facility 21

logging host inside 192.168.1.10

mtu outside 1500

mtu inside 1500

mtu dmz 1500

ip address outside pix_ext 255.255.255.248

ip address inside pix_lan 255.255.255.0

ip address dmz pix_dmz 255.255.255.0

ip audit info action alarm

ip audit attack action alarm

pdm history enable

arp timeout 14400

global (outside) 1 interface

nat (inside) 0 access-list dmz

nat (inside) 1 0.0.0.0 0.0.0.0 0 0

static (dmz,outside) vpn_ext vpn_dmz netmask 255.255.255.255 0 0

access-group out in interface outside

route outside 0.0.0.0 0.0.0.0 router 1

timeout xlate 3:00: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

no snmp-server location

no snmp-server contact

snmp-server community public

no snmp-server enable traps

floodguard enable

telnet timeout 5

ssh timeout 15

console timeout 0

terminal width 80

Cryptochecksum:xxxxxxx

: end

[gfullage]

If you want to do IPSec encapsulation within UDP (the Cisco proprietary version) this is negotiated between client and concentrator using ISAKMP, so you need to let that through with the following:

access-list out permit udp any host vpn_ext eq isakmp

For IPSec encapsulation within TCP, the client and concentrator do send every packet in a TCP stream, but I do know that not every TCP connection rule is strictly adhered to, so it may be that the PIX, being a stateful firewall, doesn't like it and drops the packets.

If I were you I would forget about encapsulation specifically, and allow the concentrator and client to automatically negotiate NAT-T, which is the standards based IPsec UDP encapsulation (as opposed to Cisco's proprietary version detailed above). This runs on UDP/4500, so I'd change the ACL to the following:

access-list out permit udp any host vpn_ext eq isakmp

access-list out permit udp any host vpn_ext eq 4500

Then all you need to do is on the concentrator, make sure NAT-T is checked under Configuration | System | Tunneling Protocols | IPSec | NAT Transparency section. The client and concentrator will automatically detect the PIX in between and you don't need to do anything else.

[ehirsel]

Other items to check are:

1. Make sure that a default gateway is configured on the vpn concentrator. It should point to the pix dmz interface's address.

2. Check the log on the vpn concentrator to see if there are any relevant messages. Do the same on the pix.

If, regardless of using NAT-T or ipsec tunnelling over tcp or udp, you are still having issues run the pix caputre command on both the outside and the dmz interfaces and look for the vpn traffic.

One other note is that I see that your pix interfaces are configured for auto-negotiation. I would explicitly state the line speed and duplex setting, on the switch as well as the pix.