Rhubarb
asked on
PIX to PIX VPN with PATing PIX in between
Hi,
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 10.10.10.10 on its external. It sits behind their PIX with 10.10.10.1 on its internal and THEIR-PIX-WITH-INTERNET-AD
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_bloc
VPN Peer:ISAKMP: Peer Info for <THEIR-PIX-WITH-INTERNET-A
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_bloc
ISAKMP: sa not found for ike msg
(10.10.10.10 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?
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 10.10.10.10 on its external. It sits behind their PIX with 10.10.10.1 on its internal and THEIR-PIX-WITH-INTERNET-AD
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_bloc
VPN Peer:ISAKMP: Peer Info for <THEIR-PIX-WITH-INTERNET-A
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_bloc
ISAKMP: sa not found for ike msg
(10.10.10.10 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?
ASKER
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.
Thanks.
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.
Thanks.
>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
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
ASKER
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.
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.
ASKER
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 10.10.10.10 given the NATP in action?
I assume this is correct even though the external address of my other PIX is actually 10.10.10.10 given the NATP in action?
ASKER CERTIFIED SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
ASKER
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.
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:
https://www.experts-exchange.com/help.jsp#hs5
Thanks for your attention!
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:
https://www.experts-exchange.com/help.jsp#hs5
Thanks for your attention!
ASKER
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!
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!
static (inside,outside) a.b.c.d 10.10.10.10 netmask 255.255.255.255
and an accompanying acl entry:
access-list outside_in permit ip any host a.b.c.d