PIX to PIX VPN with PATing PIX in between


I used to have a PIX to PIX VPN tunnel - When I set it up, it was quite straight forward with both PIXs having public Internet IPs.

Due to a change at one site (they've run out of external IPs) I have to move my PIX behind their PIX which provides PAT for the hosts behind it.

I enabled nat-translation on both of my PIXs and moved my PIX behind theirs. They've given my PIX on their network unrestricted access to my (still) Internet exposed PIX - however, my tunnel will not come up.

To summarise, the network is now my PIX with 172.16.20.x on its internal interface and on its external. It sits behind their PIX with on its internal and THEIR-PIX-WITH-INTERNET-ADDRESS on it’s outside. And the tunnel from my PIX on their network is supposed to terminate on my PIX (as it used to) with external address MY-PIX-INTERNET-ADDRESS.

The debug on the Internet exposed PIX shows:

ISAKMP (0): Checking ISAKMP transform 1 against priority 10 policy
ISAKMP:      encryption DES-CBC
ISAKMP:      hash MD5
ISAKMP:      default group 1
ISAKMP:      auth pre-share
ISAKMP:      life type in seconds
ISAKMP:      life duration (basic) of 1000
ISAKMP (0): atts are acceptable. Next payload is 0
ISAKMP (0): processing vendor id payload

ISAKMP (0:0): vendor ID is NAT-T
ISAKMP (0): processing vendor id payload

ISAKMP (0:0): vendor ID is NAT-T
ISAKMP (0): SA is doing pre-shared key authentication using id type ID_IPV4_ADDR
ISAKMP (0:0): sending NAT-T vendor ID - rev 2 & 3
ISAKMP (0:0): Detected port floating
return status is IKMP_NO_ERROR

Which, until this points looks pretty good...

crypto_isakmp_process_block:src:<THEIR-PIX-WITH-INTERNET-ADDRESS>, dest:<MY-PIX-INTERNET-ADDRESS> spt:1 dpt:500
VPN Peer:ISAKMP: Peer Info for <THEIR-PIX-WITH-INTERNET-ADDRESS>/500 not found - peers:0

Which is where it appears to fall down. At the same time, my PIX behind theirs shows:

ISAKMP (0:0): sending NAT-T vendor ID - rev 2 & 3
ISAKMP (0): beginning Main Mode exchange
crypto_isakmp_process_block:src:<MY-PIX-WITH-INTERNET-ADDRESS>, dest: spt:500 dpt:500
ISAKMP: sa not found for ike msg

( is the external address of my PIX behind theirs, it serves 172.16.20.x on its internal)

I'm confused by the two PIXs not using the same ports. In fact, I'm confused why it's not working in general, any thoughts?
Who is Participating?
>my publicly exposed PIX has the public address of their PATing PIX as the intended endpoint for the tunnel
Yes. But I'm not at all convinced that they have given your public IP address full access.
Can you confirm that nat-traversal is enabled on all 3 PIX's

  isakmp nat-traversal 20
Does the PIX in front of yours with the "real" public IP address have a static 1-1 NAT for a public IP address for your PIX. i.e.
  static (inside,outside) a.b.c.d netmask

and an accompanying acl entry:
  access-list outside_in permit ip any host a.b.c.d

RhubarbAuthor Commented:
Thanks lrmoore,

RE: Static No, their PIX purely provides mine with PATing - Is this required for NAT-T to work?

RE Incoming ACL, I belive so, but I will check.

KuppingerCole Reviews AlgoSec in Executive Report

Leading analyst firm, KuppingerCole reviews AlgoSec's Security Policy Management Solution, and the security challenges faced by companies today in their Executive View report.

>their PIX purely provides mine with PATing
Which ports? you need at least UDP 500 and UDP 4500 and esp
AND nat-traversal must be enabled on both yours and their PIX
RhubarbAuthor Commented:
That was the original config, to debug I've asked for (and, I'm told received) unfettered access both to and from the address of my publicly exposed PIX.

I don't know if it's changed or I only just spotted it but the publicly exposed PIX will, at times, believe it has created a tunnel. It will report success with Peers: 1 and then immediately afterwards tear it down. (This appears perhaps once every 5 to 10 minutes)

In the mean time the PIX on the private LAN continues to attempt IKE negotiation.
RhubarbAuthor Commented:
One last thing occurs to me - my publicly exposed PIX has the public address of their PATing PIX as the intended endpoint for the tunnel.

I assume this is correct even though the external address of my other PIX is actually given the NATP in action?
RhubarbAuthor Commented:
I am assured this is the case, I'll try and get a copy of their config to confirm this though.

With regards to nat-traversal, it is certainly enabled on both of my PIXs, and I am told it is on theirs. Again, I will confirm this.
Any news? Updates? Progress?

Are you still working on this?
Have you found a solution?
Do you need more information?

This question will be classified as abandoned soon if we don't get some feedback from you.

Can you close out this question? See here for details:

Thanks for your attention!
RhubarbAuthor Commented:
Sorry for the delay - I've been away for sometime.

You were quite right, despite the assurance that my PIX had been given a public IP with no filtering, this was not the case. Fixed that, and it all worked like magic.

Thanks for you help and patience!
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.