PIX 501 pass-through for VPN traffic


I'm trying to configure my PIX 501, so that end-users can connect to a remote VPN concentrator and perform work.  They are currently able to authenticate, but once authenticated they are unable to connect to any servers.  

Here is the configuration and any help would be greatly appreciated.

sh config
: Saved
: Written by enable_15 at 02:05:47.173 CST Thu Nov 30 2006
PIX Version 6.3(5)
interface ethernet0 auto
interface ethernet1 100full
nameif ethernet0 outside security0
nameif ethernet1 inside security100
enable password ckTqTMBDn/ZH5nDx encrypted
passwd ckTqTMBDn/ZH5nDx encrypted
hostname pixfirewall
domain-name tros.tma.osd.mil
clock timezone CST -6
clock summer-time MDT recurring
fixup protocol dns maximum-length 512
fixup protocol esp-ike
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
pager lines 24
mtu outside 1500
mtu inside 1500
ip address outside
ip address inside
ip audit info action alarm
ip audit attack action alarm
pdm logging informational 100
pdm history enable
arp timeout 14400
global (outside) 1 interface
nat (inside) 1 0 0
route outside 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 sip-disconnect 0:02:00 sip-invite 0:03:00
timeout uauth 0:05:00 absolute
aaa-server TACACS+ protocol tacacs+
aaa-server TACACS+ max-failed-attempts 3
aaa-server TACACS+ deadtime 10
aaa-server RADIUS protocol radius
aaa-server RADIUS max-failed-attempts 3
aaa-server RADIUS deadtime 10
aaa-server LOCAL protocol local
http server enable
http inside
no snmp-server location
no snmp-server contact
snmp-server community public
no snmp-server enable traps
floodguard enable
isakmp nat-traversal 20
telnet inside
telnet timeout 5
ssh timeout 5
console timeout 20
dhcpd address inside
dhcpd dns
dhcpd lease 3600
dhcpd ping_timeout 750
dhcpd enable inside
terminal width 80
pixfirewall# exit
Who is Participating?
jjoseph_xConnect With a Mentor Commented:
The people behind that PIX who try to connect to the VPN Concentrator have PAT'ed addresses.  This means that source port is changed by the firewall which means that the checksum in the ESP header isn't correct anymore.

To get around this Cisco has two solutions:

1)  On the VPN Concentrators you can use a TCP-based VPN connection (with the Cisco VPN Client) that goes over port 10,000 instead of the traditional UDP-based IPSEC VPN.

2)  Activate nat traversal for the VPN connection  (for example on your PIX the line: "isakmp nat-traversal 20" does just that... however that's only for incoming connections).

You also have the "fixup protocol esp-ike" which should allow one (and only person at a time) to connect to VPN from behind a PAT'ed device without worry about the NAT-T problem (but the problem, other than the only-one connection thing, is that it means that you can't have IPSEC vpn on your PIX...  not site-to-site nor for EasyVPN users).
It could be a NAT-Traversal issue on the other end (it usually is).  Is a Cisco VPN Concentrator to which they're connecting?  If so the VPN admin could either setup the TCP IPSEC VPN on port 10,000 (Cisco's work-around to nat-t issues) or active Nat Traversal on the VPN.

If it's another type of VPN, they'll have to see if it supports nat-t and configure it appropriately.
bbanis2kAuthor Commented:
It's a Cisco VPN concentrator...  A lot of people are able to telnet just fine...it's just the people behind the PIX 501.  Does that sound right?
Protect Your Employees from Wi-Fi Threats

As Wi-Fi growth and popularity continues to climb, not everyone understands the risks that come with connecting to public Wi-Fi or even offering Wi-Fi to employees, visitors and guests. Download the resource kit to make sure your safe wherever business takes you!

Tim HolmanCommented:
Put this in:

isakmp enable outside

Change your PIX enable passwords as soon as you can - the hashes you've posted up above are crackable, plus you've listed the external IP of your firewall and domain name, which a hacker could use to his/her advantage.
bbanis2kAuthor Commented:
I will try everything recommended here.

bbanis2kAuthor Commented:
Hey tim_holman,

I can't run the command "isakmp enable outside".  I get the below error message:

ISAKMP cannot be enabled since fixup protocol esp-ike is enabled.  Please correc
t your configuration and re-issue the command

The problem isn't the missing "isakmp enable outside" since you aren't going to be a VPN endpoint.  Like I mentioned earlier, that fixup means that you can't use configure your PIX for site-to-site or client IPSEC vpn (which are the only times that you'd need to the "isakmp enable outside".
bbanis2kAuthor Commented:
That makes sense....  Thanks
Unfortunately in these cases, it's kind of out of your hands because the problem is the VPN end-point.

So the administrator of the VPN Concentrator might have to make a change on his/her end (if they're willing/able to do it).

Tim HolmanCommented:
Ditch it then:

no fixup protocol esp-ike
isakmp enable outside

To proxy VPN connections, I think you do need to enable isakmp.
bbanis2kAuthor Commented:
Hi Tim,

I tried that, and when I do the initiation of a VPN connection terminates locally at the client. :-(

Tim HolmanCommented:
OK then, put it back.

fixup protocol esp-ike
isakmp nat-traversal

...this time, try setting up some debugs as below, and capture what events you're seeing when clients experience a failure:

debug crypto engine—Display debug messages about crypto engines, which perform encryption and decryption.
debug crypto isakmp—Display messages about IKE events.
debug crypto ipsec—Display IPSec events.
term mon (display to screen)
term no mon (to disable)

I don't mean to be a pain.  And I certain don't want to sound at all condescending; but you know that 9 times of out 10, when someone can't connect to a remote VPN and they are using a PAT'ed address it's a nat traversal problem (there are literally a bunch of PAQs that had exactly the same problem and the solution was almost universally to enable nat-t on the remote vpn end-point).

Rather than logging the events, the 1st thing that bbanis2k should try is the get the nat-t enabled, or use the TCP IPSEC implementation on the VPN Concentrator.  If that doesn't work, THEN you start logging (i.e. try the easy solution first, then worry about the harder stuff - like sorting through the logs - if the easy solution fails...  especially since a) the logs are cryptic and b) it's probably the remote iksamp/ipsec logs that he'd need more than anything else).
bbanis2kAuthor Commented:

You mean enabling the below command on the remote firewall, correct?  The remote Cisco VPN is behind a PIX 525.

isakmp nat-traversal 20
Yes, that's the command that you'd need to enable.
also, though I dunno why, some people have had to disable and then re-enable isakmp on the outside interface after adding the nat-t command:

no isakmp enable outside
isakmp enable outside

you might not need to do that though.
bbanis2kAuthor Commented:
The below command on the remote firewall did the trick...

isakmp nat-traversal 20
Question has a verified solution.

Are you are experiencing a similar issue? Get a personalized answer when you ask a related question.

Have a better answer? Share it in a comment.

All Courses

From novice to tech pro — start learning today.