Site to Site VPN

Unanswered Question
Apr 6th, 2010

Hello

We are trying to make a site to site VPN with 2 ASA devices.

The HQ is ising a Cisco ASA 5520 while the remote end is using a 5505

The HQ using a IP range of 10.8.x

And the remote end uses 10.9.23.x

The when the remote end brings does a ping to 10.8.x.x then the VPN initiates and both the HQ and the remote site can ping all the sites.

However if the VPN is down then the HQ can not bring the VPN up.

Does anyone know how we can setup the VPN so both sites can bring up the VPN?

Thanks

I have this problem too.
0 votes
  • 1
  • 2
  • 3
  • 4
  • 5
Overall Rating: 0 (0 ratings)
Loading.
Jennifer Halim Tue, 04/06/2010 - 04:10

If the outside ip address of both ASA is static, both should be able to initiate the VPN connection.

Can you share config from HQ end?

asmith1972 Tue, 04/06/2010 - 05:59

Yes both of the outside interfaces at the HQ and the remote site use satic public IPs.

I've attached the config of the HQ

This is what the remote site say they have setup...

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

tunnel-group [peer host ip] type ipsec-l2l

tunnel-group [peer host ip] ipsec-attributes

pre-shared-key [key]

crypto isakmp identity address

crypto isakmp enable outside

crypto isakmp policy 10

authentication pre-share

encryption aes

hash sha

group 2

lifetime 86400

access-list 104 permit ip [inside block] [farside block]

crypto ipsec transform-set rack esp-aes esp-sha-hmac

crypto map rackmap 10 match address 104

crypto map rackmap 10 set peer [peer host ip]

crypto map rackmap 10 set transform-set rack

crypto map rackmap interface outside

crypto isakmp identity address

crypto isakmp enable outside

crypto map rackmap 10 set security-association lifetime seconds 3600

crypto map rackmap 10 set security-association lifetime kilobytes 4608000

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

crypto ipsec transform-set rack esp-3des esp-sha-hmac

crypto ipsec security-association lifetime seconds 28800

crypto ipsec security-association lifetime kilobytes 4608000

access-list 104 extended permit ip 10.9.23.0 255.255.255.0 10.8.0.0 255.255.0.0

access-list 104 extended permit ip 10.9.23.0 255.255.255.0 10.1.0.0 255.255.0.0

crypto map rackmap 10 match address 104

crypto map rackmap 10 set peer xxxxxxxxx

crypto map rackmap 10 set transform-set rack

crypto map rackmap 10 set security-association lifetime seconds 28800

crypto map rackmap 10 set security-association lifetime kilobytes 4608000

crypto map rackmap 10 set reverse-route

crypto map rackmap interface outside

crypto isakmp identity address

crypto isakmp enable outside

crypto isakmp policy 10

authentication pre-share

encryption 3des

hash sha

group 2

lifetime 3600

static (inside,outside) 10.9.23.0  access-list 300

static (dmz,outside) 10.9.23.0  access-list 301

access-list 300 extended permit ip 192.168.100.0 255.255.255.0 10.8.0.0 255.255.0.0

access-list 300 extended permit ip 192.168.100.0 255.255.255.0 10.1.0.0 255.255.0.0

access-list 301 extended permit ip 192.168.50.0 255.255.255.0 10.8.0.0 255.255.0.0

access-list 301 extended permit ip 192.168.50.0 255.255.255.0 10.1.0.0 255.255.0.0

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

Attachment: 
Jennifer Halim Tue, 04/06/2010 - 06:12

Seems like you are statically NATing both inside and dmz subnet to 10.9.23.0/24, which is incorrect and will cause a lot of issue.

You would need to NAT inside network to a different subnet to when you are NATing the dmz network.

It will be 1 to 1 NATing, so if inside host 192.168.100.5 trying to access the remote site, it will be NATed to 10.9.23.5, same for dmz host 192.168.50.5 trying to access the remote site, it will be NATed to 10.9.23.5 which is incorrect. The ASA will not know where to translate the ip address back if both is in the xlate table.

You would need to NAT to 2 different subnet, example:

static (inside,outside) 10.9.23.0 access-list 300

static (dmz,outside) 10.9.24.0 access-list 301

Then add the following crypto ACL:

access-list 104 permit ip 10.9.24.0 255.255.255.0 10.8.0.0 255.255.0.0

access-list 104 permit ip 10.9.24.0 255.255.255.0 10.1.0.0 255.255.0.0

On the remote end, they would also need to add the following crypto ACL and corresponding NAT statement:

access-list permit ip 10.8.0.0 255.255.0.0 10.9.24.0 255.255.255.0

access-list permit ip 10.1.0.0 255.255.0.0  10.9.24.0 255.255.255.0

And please "clear xlate" and clear the VPN tunnel after the configuration changes.

droeun141 Tue, 04/06/2010 - 06:19

Did you omit part of the config? seems like your phase I attributes also don't match.

asmith1972 Tue, 04/06/2010 - 06:26

Hi

No that is all the config we were given

Which bit of phase 1 doesn't match?

On the NAT questions, I know the remote end needs to do NATing becuase there local IP range is 192.168.10.x but we jsut use 10.x.x.x.

Are you saying we should be unticking the "Enable NAT-T" at our end?

Thanks

droeun141 Tue, 04/06/2010 - 06:33

Site I has AES & lifetime of 86400 & site II has 3DES & lifetime of 3600.  These attributes need to match.

crypto isakmp policy 10
authentication pre-share
encryption aes
hash sha
group 2
lifetime 86400

crypto isakmp policy 10
authentication pre-share
encryption 3des
hash sha
group 2
lifetime 3600

asmith1972 Tue, 04/06/2010 - 07:36

Sorry we were sent the wrong setup at the remote end there config is:

crypto ipsec transform-set rack esp-3des esp-sha-hmac

crypto ipsec security-association lifetime seconds 28800

crypto ipsec security-association lifetime kilobytes 4608000

access-list 104 extended permit ip 10.9.23.0 255.255.255.0 10.8.0.0 255.255.0.0

access-list 104 extended permit ip 10.9.23.0 255.255.255.0 10.1.0.0 255.255.0.0

crypto map rackmap 10 match address 104

crypto map rackmap 10 set peer xxxxx

crypto map rackmap 10 set transform-set rack

crypto map rackmap 10 set security-association lifetime seconds 28800

crypto map rackmap 10 set security-association lifetime kilobytes 4608000

crypto map rackmap 10 set reverse-route

crypto map rackmap interface outside

crypto isakmp identity address

crypto isakmp enable outside

crypto isakmp policy 10

authentication pre-share

encryption 3des

hash sha

group 2

lifetime 3600

static (inside,outside) 10.9.23.0  access-list 300

static (dmz,outside) 10.9.23.0  access-list 301

access-list 300 extended permit ip 192.168.100.0 255.255.255.0 10.8.0.0 255.255.0.0

access-list 300 extended permit ip 192.168.100.0 255.255.255.0 10.1.0.0 255.255.0.0

access-list 301 extended permit ip 192.168.50.0 255.255.255.0 10.8.0.0 255.255.0.0

access-list 301 extended permit ip 192.168.50.0 255.255.255.0 10.1.0.0 255.255.0.0

----

The HQ is as attached

Attachment: 
droeun141 Tue, 04/06/2010 - 07:35

Based on your setup, when connecting from core to branch you need to connect to 10.29.23.x instead of 192.168.x.x (FW translates 10 to 192)

What halijenn is saying is that the issue you're having is that you have two policy NAT statements using the same outside address range.  It shouldn't be a problem initiating traffic from the remote side (FW builds session) but when the core initiates traffic, the remote site doesn't know where/how to translate it because 192.168.100.x & 192.168.50.x coexist.

To fix it, you need your DMZ translated to another outside block -

static (inside,outside) 10.9.23.0  access-list 300
static (dmz,outside) 10.9.24.0  access-list 301

access-list 300 extended permit ip 192.168.100.0 255.255.255.0 10.8.0.0 255.255.0.0
access-list 300 extended permit ip 192.168.100.0 255.255.255.0 10.1.0.0 255.255.0.0

access-list 301 extended permit ip 192.168.50.0 255.255.255.0 10.8.0.0 255.255.0.0
access-list 301 extended permit ip 192.168.50.0 255.255.255.0 10.1.0.0 255.255.0.0

Crypto ACL also needs to reflect the change on both sides -

Core:

access-list 104 permit ip 10.8.0.0 255.255.0.0 10.9.23.0 255.255.255.0

access-list 104 permit ip 10.1.0.0 255.255.0.0 10.9.23.0 255.255.255.0

access-list 104 permit ip 10.8.0.0 255.255.0.0 10.9.24.0 255.255.255.0

access-list 104 permit ip 10.1.0.0 255.255.0.0  10.9.24.0 255.255.255.0

Remote:

access-list 104 permit ip 10.9.23.0 255.255.255.0 10.8.0.0 255.255.0.0

access-list 104 permit ip 10.9.23.0 255.255.255.0 10.1.0.0 255.255.0.0

access-list 104 permit ip 10.9.24.0 255.255.255.0 10.8.0.0 255.255.0.0

access-list 104 permit ip 10.9.24.0 255.255.255.0 10.1.0.0 255.255.0.0

When connecting from core to branch you need to specify the NAT'd prefix instead of the actual IP (Instead of connecting to 192.168.100.25, connect to 10.9.23.25, and instead of connecting to 192.168.50.137, connect to 10.9.24.137 instead, etc.)

Actions

This Discussion