cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
689
Views
0
Helpful
8
Replies

PIX-PIX VPN Trouble

DavidBReid
Level 1
Level 1

I am establishing Site-to-Site VPN using PIX-515 (Corporate) and PIX-501 (Branch) through the internet. I have public addresses assigned on each end and private subnets behind. I can see that the tunnels have been established:

***************************************************

sh crypto ipsec sa

interface: outside

Crypto map tag: ATL, local addr. XX.XX.XX.XX

local ident (addr/mask/prot/port): (172.16.100.0/255.255.255.0/0/0)

remote ident (addr/mask/prot/port): (172.16.99.0/255.255.255.0/0/0)

current_peer: YY.YY.YY.YY:500

PERMIT, flags={origin_is_acl,}

#pkts encaps: 11, #pkts encrypt: 11, #pkts digest 11

#pkts decaps: 0, #pkts decrypt: 0, #pkts verify 0

#pkts compressed: 0, #pkts decompressed: 0

#pkts not compressed: 0, #pkts compr. failed: 0, #pkts decompress failed: 0

#send errors 1, #recv errors 0

local crypto endpt.: XX.XX.XX.XX, remote crypto endpt.: YY.YY.YY.YY

path mtu 1500, ipsec overhead 56, media mtu 1500

current outbound spi: 4baa785e

inbound esp sas:

spi: 0x90adbfe6(2427305958)

transform: esp-3des esp-md5-hmac ,

in use settings ={Tunnel, }

slot: 0, conn id: 3, crypto map: PioneerATL

sa timing: remaining key lifetime (k/sec): (4608000/26937)

IV size: 8 bytes

replay detection support: Y

inbound ah sas:

inbound pcp sas:

outbound esp sas:

spi: 0x4baa785e(1269463134)

transform: esp-3des esp-md5-hmac ,

in use settings ={Tunnel, }

slot: 0, conn id: 4, crypto map: PioneerATL

sa timing: remaining key lifetime (k/sec): (4607998/26937)

IV size: 8 bytes

replay detection support: Y

outbound ah sas:

outbound pcp sas:

***************************************************

But no connections can be established. Note that all stats except for "#pkts encaps" are "0".

I am unable to establish meaningful traffic between the sites.

I am following guidelines in dcouments found in Tech Support for establishing Site-to-Site VPN .....

Suggestions or comments welcome .....

8 Replies 8

jhaggett
Level 1
Level 1

Looks like maybe you didn't define traffic NOT to be translated on one end of your tunnel. Do you have all your access-lists and nat translations setup properly?

Thanks .....

This is the pertinent part of the ACL - other entries relate to Corp part of the network and all were working correctly. I can still access public internet traffic from both locations properly. Once this config is working, I will clone it to 3 other branches with the same setup. Some of the other subnets are already indicated on the Corp network.

access-list 101 permit icmp any any

access-list 101 permit ip 172.16.101.0 255.255.255.0 172.16.100.0 255.255.255.0

access-list 101 permit ip 172.16.100.0 255.255.255.0 172.16.99.0 255.255.255.0

access-list 140 permit ip 172.16.100.0 255.255.255.0 172.16.99.0 255.255.255.0

global (outside) 1 interface

nat (inside) 0 access-list 101

nat (inside) 1 0.0.0.0 0.0.0.0 0 0

route outside 0.0.0.0 0.0.0.0 XX.XX.XX.XX 1

route inside 172.16.101.0 255.255.255.0 172.16.100.1 1

What you show us are private ip addresses. Does that mean you have routers in front of your pixes that use public ip addresses ? Or did you anonymize your config ?

If 1, your routers should be correctly configured to let pass the ipsec/isakmp traffic through.

If 2, you could be experiencing some mismatches in policies, mutual pre-shared keys, etc.

Most of the times I print both configs and compare them line by line to find the differences. That usually reveals the error.

I did mask the public addresses in each case for security reasons - Each PIX does show the correct tunnel connection to the other peer.

I have a router in the inside interface of the PIX 515 - a 2621 configured for VOIP and connected to CCM and Unity boxes. The PIX units in each location are configured as the primary Gateways. Also have 3650 series switches in the Corporate location, and unmanaged switch in the branch.

Should I be adding ROUTE commands to identify the connection, or is that implicit in the ipsec tunnel definition?

No, you don't need route commands.

You could try the commands :

debug crypto isakmp

debug crypto ipsec

When you start the tunnel with traffic from one of the Lan's there should be a lot of logging output from both pixes. In that output, if any, you can see what goes wrong.

jayson.talaga
Level 1
Level 1

Can you provide your crypto & isakmp config information?

For PIX 515 (Corporate)

sysopt connection permit-ipsec

crypto ipsec transform-set ESP-3DES-MD5 esp-3des esp-md5-hmac

crypto map PioneerATL 10 ipsec-isakmp

crypto map PioneerATL 10 match address 140

crypto map PioneerATL 10 set peer XX.XX.XX.XX

crypto map PioneerATL 10 set transform-set ESP-3DES-MD5

crypto map PioneerATL interface outside

isakmp enable outside

isakmp key ******** address XX.XX.XX.XX netmask 255.255.255.255 no-xauth no-config-mode

isakmp identity address

isakmp policy 40 authentication pre-share

isakmp policy 40 encryption 3des

isakmp policy 40 hash md5

isakmp policy 40 group 2

isakmp policy 40 lifetime 86400

For PIX 501 (Branch Office)

sysopt connection permit-ipsec

crypto ipsec transform-set ESP-3DES-MD5 esp-3des esp-md5-hmac

crypto map PioneerATL 10 ipsec-isakmp

crypto map PioneerATL 10 match address 110

crypto map PioneerATL 10 set peer YY.YY.YY.YY

crypto map PioneerATL 10 set transform-set ESP-3DES-MD5

crypto map PioneerATL interface outside

isakmp enable outside

isakmp key ******** address YY.YY.YY.YY netmask 255.255.255.255 no-xauth no-config-mode

isakmp identity address

isakmp policy 40 authentication pre-share

isakmp policy 40 encryption 3des

isakmp policy 40 hash md5

isakmp policy 40 group 2

isakmp policy 40 lifetime 86400

Where XX.XX.XX.XX is the correct public address for the outside interface of the branch office pix and YY.YY.YY.YY is the correct public address for the outside interface of the corporate office pix.

I will check the debug output as suggested in previous posting as well .....

Thanks to all .....

From what I see above, it looks like it should work. The only information I haven't been able to verify is on the Branch Office side. Can you provide the NAT info and access-list 110 information from the Branch PIX?