Problem bringing up Site-to-Site VPN tunnel Pix 515E -

Unanswered Question
Oct 1st, 2007

Hello,

I am trying to migrate our current L2L vpn connections from our VPN concentrator to be implemented in our PIX515e, I am having issues with other peer-side which I cannot bring up tunnel over public network, other side uses 3600 series vpn router. My local host is the one initiating the connection for this tunnel, but when we fire up the application or do a telnet test to destination host on pre-defined TCP port 8893 it does not bring up tunnel, other side indicates that I am not even hitting their gateway. I setup firewall logs to see conversation but I do not see in logs even getting to IPsec Phase-1 . The other side requests are that my local host comes to them with its unique public IP, I have static nat for my local host with public IP .. anything that I could possibly be missing. Attached is partial fw log and config. PIX ver 6.3(3).

Rgds

Jorge

I have this problem too.
0 votes
  • 1
  • 2
  • 3
  • 4
  • 5
Overall Rating: 4 (3 ratings)
Loading.
Jon Marshall Tue, 10/02/2007 - 00:37

Hi Jorge

You are translating 10.3.2.78 to 67.43.92.117 but your crypto access-list map reads

access-list outside_cryptomap_20 permit ip host 10.3.2.78 host 198.80.189.71

access-list outside_cryptomap_20 permit tcp host 10.3.2.78 host 198.80.189.7

Can you change to read

access-list outside_cryptomap_20 permit ip host 67.43.92.117 host 198.80.189.71

access-list outside_cryptomap_20 permit tcp host 67.43.92.117 host 198.80.189.7

The NAT of the source IP address will happen before the traffic is inspected against the crypto map access-list which is why you are not seeing any activity from your end.

HTH

Jon

JORGE RODRIGUEZ Tue, 10/02/2007 - 03:59

Thanks Jon for the reply, I will check this in morning, and post results later after test.

Rgds

Jorge

Jon Marshall Tue, 10/02/2007 - 04:35

No problem Jorge. One thing i forgot to mention is that you will need to make sure the access-list on the router at the other end also reflects the public IP address you are using.

Jon

JORGE RODRIGUEZ Tue, 10/02/2007 - 12:33

Thanks Jon, I made the changes, however testers cannot test till tomorrow .. will post results later..,yes other side has confirmed their entries for our side.

The config looks as this but will wait for reults tomorrow when they test and fire up fw logs.

sysopt connection timewait

sysopt connection permit-ipsec

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

crypto ipsec transform-set ESP-3DES-SHA esp-3des esp-sha-hmac

crypto map outside_map 20 ipsec-isakmp

crypto map outside_map 20 match address outside_cryptomap_20

crypto map outside_map 20 set peer 198.80.144.75

crypto map outside_map 20 set transform-set ESP-3DES-SHA

crypto map outside_map interface outside

isakmp enable outside

isakmp key ******** address 198.80.144.75 netmask 255.255.255.255 no-xauth no-config-mode

isakmp nat-traversal 20

isakmp policy 20 authentication pre-share

isakmp policy 20 encryption 3des

isakmp policy 20 hash sha

isakmp policy 20 group 2

isakmp policy 20 lifetime 86400

access-list inside_nat0_outbound permit ip host 10.3.2.78 host 198.80.189.71

access-list outside_cryptomap_20 permit ip host 67.43.92.117 host 198.80.189.71

access-list outside_cryptomap_20 permit tcp host 67.43.92.117 host 198.80.189.71

Rgds

Jorge

When you think you are done with the configs, you should run the

show crypto ipsec sa = this one will show you the current peer, remote peer and the way your access-lists are setup. This is IKE phase I

Follow this command by the

show crypto isa sa = this will show you IKE Phase 2 to see if your isakmp policies match along with the status of the tunnel. You should get something like:

PIX# sh cryp isa sa

Total : 1

Embryonic : 0

dst src state pending created

localpeer_IP remotepeer_IP QM_IDLE 0 5

PIX#

If this one is blank, your config is not right.

Julio,

JORGE RODRIGUEZ Wed, 10/03/2007 - 14:38

Jon, just wanted to drop and update , the test was not successful, the suggested acl configuration was fine and was part of couple other problems I had, after reading L2L implementations on cisco I was missing tunel policy in the IPsec rules, after this was defined the tunnel came up.

Thank you for your help on this.

IPSEC(spi_response): getting spi 0x8abd6417(2327667735) for SA

from 198.80.144.75 to 67.43.92.4 for prot 3

IPSEC(validate_proposal_request): proposal part #1,

(key eng. msg.) dest= 198.80.144.75, src= 67.43.92.4,

dest_proxy= 198.80.189.71/255.255.255.255/6/8893 (type=1),

src_proxy= 67.43.92.117/255.255.255.255/6/0 (type=1),

protocol= ESP, transform= esp-3des esp-sha-hmac ,

lifedur= 0s and 0kb,

spi= 0x0(0), conn_id= 0, keysize= 0, flags= 0x24

IPSEC(key_engine): got a queue event...

IPSEC(initialize_sas): ,

(key eng. msg.) dest= 67.43.92.4, src= 198.80.144.75,

dest_proxy= 67.43.92.117/255.255.255.255/6/0 (type=1),

src_proxy= 198.80.189.71/255.255.255.255/6/8893 (type=1),

protocol= ESP, transform= esp-3des esp-sha-hmac ,

lifedur= 3600s and 4608000kb,

spi= 0x8abd6417(2327667735), conn_id= 1, keysize= 0, flags= 0x25

IPSEC(initialize_sas): ,

(key eng. msg.) src= 67.43.92.4, dest= 198.80.144.75,

src_proxy= 67.43.92.117/255.255.255.255/6/0 (type=1),

dest_proxy= 198.80.189.71/255.255.255.255/6/8893 (type=1),

protocol= ESP, transform= esp-3des esp-sha-hmac ,

lifedur= 3600s and 4608000kb,

spi= 0x332169bb(857827771), conn_id= 2, keysize= 0, flags= 0x25

Actions

This Discussion