Site-To_Site VPN problem

[Stephen Sisson]

Hello everyone

I'm installing a new site-to-site VPN connection between two sites, having problems bringing the tunnel online.

We have two ASA 5505 firewalls - one at our Central site, and another for our customer at the Remote site.

I wiped both firewalls with write erase, installed the latest IOS version 9.2 on both firewalls.
I'm not sure if the new IOS is causing the problem, we have several site-to-site vpn’s all working with IOS 8.4 5

I'm enclosing the configs for both ASA firewalls for you to review and see if I missed something or what's changed in the IOS that maybe causing our tunnel issue.

Thank you 

[Jouni Forss]

Hi,

Check your Crypto ACL configurations.

Instead of using the "any" in the Crypto ACL I would suggest replacing it with the actual subnet(s) on each site. Now you are using "any" as the source in both sites ACLs so they wont match.

So I would suggest

CENTRAL ASA
access-list REMOTE-ONE-L2LVPN extended permit ip 10.10.1.0 255.255.255.0 10.4.1.0 255.255.255.0

REMOTE ASA
access-list net-remote extended permit ip 10.4.1.0 255.255.255.0 10.10.1.0 255.255.255.0

This is the only problem that I can see at the moment with a quick glance.

Will have another look if I have missed something.

Hope this helps :)

- Jouni

[Stephen Sisson]

Hello Jouni

Thanks for your response, we have updated both firewalls and still not able to bring the tunnel online.

[Jouni Forss]

Hi,

Can you share the "packet-tracer" outputs from both sites.

CENTRAL

packet-tracer input inside tcp 10.10.1.100 12345 10.4.1.100 80

REMOTE

packet-tracer input inside tcp 10.4.1.100 12345 10.10.1.100 80

Do the outputs twice initially and share the second results.

Also I would suggest that you use the above commands on the units and then check the output of the following command multiple times and share it. You might have to do the "packet-tracer" and the below command multiple of times to view to get the correct information if you are unlucky with the timing.

show crypto ikev1 sa

I could not see any problems with the NAT or VPN configurations. Unless ofcourse you have errors in the VPN peer IP addresses used in the configurations. Double checks those.

Also I guess its possible that you have misstyped the Pre Shared Key used in the configurations. You can confirm the current PSK configured on the units by issuing the command

more system:running-config

This will list the same configuration but it will show the PSKs in clear text so you can actually check if they match.

- Jouni

[Stephen Sisson]

Central site

packet-tracer input inside tcp 10.10.1.100 12345 10.4.1.1$

Phase: 1
Type: ACCESS-LIST
Subtype:
Result: ALLOW
Config:
Implicit Rule
Additional Information:
MAC Access list

Phase: 2
Type: UN-NAT
Subtype: static
Result: ALLOW
Config:
nat (inside,outside) source static any any destination static REMOTE-ONE REMOTE-ONE
Additional Information:
NAT divert to egress interface outside
Untranslate 10.4.1.100/80 to 10.4.1.100/80

Phase: 3
Type: NAT
Subtype:
Result: ALLOW
Config:
nat (inside,outside) source static any any destination static REMOTE-ONE REMOTE-ONE
Additional Information:
Static translate 10.10.1.100/12345 to 10.10.1.100/12345

Phase: 4
Type: NAT
Subtype: per-session
Result: ALLOW
Config:
Additional Information:

Phase: 5
Type: IP-OPTIONS
Subtype:
Result: ALLOW
Config:
Additional Information:

Phase: 6
Type: NAT
Subtype: rpf-check
Result: ALLOW
Config:
nat (inside,outside) source static any any destination static REMOTE-ONE REMOTE-ONE
Additional Information:

Phase: 7
Type: NAT
Subtype: per-session
Result: ALLOW
Config:
Additional Information:

Phase: 8
Type: IP-OPTIONS
Subtype:
Result: ALLOW
Config:
Additional Information:

Phase: 9
Type: FLOW-CREATION
Subtype:
Result: ALLOW
Config:
Additional Information:
New flow created with id 817, packet dispatched to next module

Result:
input-interface: inside
input-status: up
input-line-status: up
output-interface: outside
output-status: up
output-line-status: up
Action: allow

Remote site

packet-tracer input inside tcp 10.4.1.100 12345 10.10.1.1$

Phase: 1
Type: ACCESS-LIST
Subtype:
Result: ALLOW
Config:
Implicit Rule
Additional Information:
MAC Access list

Phase: 2
Type: UN-NAT
Subtype: static
Result: ALLOW
Config:
nat (inside,outside) source static any any destination static net-remote net-remote
Additional Information:
NAT divert to egress interface outside
Untranslate 10.10.1.100/80 to 10.10.1.100/80

Phase: 3
Type: NAT
Subtype:
Result: ALLOW
Config:
nat (inside,outside) source static any any destination static net-remote net-remote
Additional Information:
Static translate 10.4.1.100/12345 to 10.4.1.100/12345

Phase: 4
Type: NAT
Subtype: per-session
Result: ALLOW
Config:
Additional Information:

Phase: 5
Type: IP-OPTIONS
Subtype:
Result: ALLOW
Config:
Additional Information:

Phase: 6
Type: NAT
Subtype: rpf-check
Result: ALLOW
Config:
nat (inside,outside) source static any any destination static net-remote net-remote
Additional Information:

Phase: 7
Type: NAT
Subtype: per-session
Result: ALLOW
Config:
Additional Information:

Phase: 8
Type: IP-OPTIONS
Subtype:
Result: ALLOW
Config:
Additional Information:

Phase: 9
Type: FLOW-CREATION
Subtype:
Result: ALLOW
Config:
Additional Information:
New flow created with id 774, packet dispatched to next module

Result:
input-interface: inside
input-status: up
input-line-status: up
output-interface: outside
output-status: up
output-line-status: up
Action: allow

After running the command we see both firewalls have the same pre shared key

[Jouni Forss]

Hi,

Neither side lists no Phase for VPN.

Are you sure the ACLs are correct?

- Jouni

[Stephen Sisson]

Jouni,

The only thing I found in the config on the Central site with object name

object network REMOTE-ONE

access-list REMOTE-ONE-L2LVPN extended permit ip any 10.4.1.0 255.255.255.0

I changed the access list to use REMOTE-ONE

changed the crypto map 

crypto map cryptomap 1 match address REMOTE-ONE

still the tunnel is down

Central site access-list

access-list REMOTE-ONE extended permit ip 10.10.1.0 255.255.255.0 10.4.1.0 255.255.255.0

Remote Site

access-list net-remote extended permit ip 10.4.1.0 255.255.255.0 10.10.1.0 255.255.255.0

[Jouni Forss]

Hi,

I actually just now noticed something on both of the ASAs.

Look at the Crypto Map configurations

CENTRAL

crypto map cryptomap 1 match address REMOTE-ONE-L2LVPN
crypto map CRYPTOMAP 1 set peer 209.x.x.x
crypto map CRYPTOMAP 1 set ikev1 transform-set ESP-AES-256-SHA
crypto map CRYPTOMAP 1 set reverse-route
crypto map CRYPTOMAP interface outside

REMOTE

crypto map cryptomap 1 match address net-remote
crypto map CRYPTOMAP 1 set peer 98.x.x.x
crypto map CRYPTOMAP 1 set ikev1 transform-set ESP-AES-256-SHA
crypto map CRYPTOMAP 1 set reverse-route
crypto map CRYPTOMAP interface outside

Notice that in both ASAs the line that defines the Crypto ACL is actually using different "crypto map" name. Its written in normal letters while the rest of the configuration uses name with capital letters.

So please change those configurations on both units.

CENTRAL

no crypto map cryptomap 1 match address <acl name>
crypto map CRYPTOMAP 1 match address <acl name>

REMOTE

no crypto map cryptomap 1 match address <acl name>
crypto map CRYPTOMAP 1 match address <acl name>

Hope this helps :)

- Jouni

[Stephen Sisson]

Dude - you’re kidding me, after changing this tunnel came online.

Once again you saved the day - Thank you Jouni, you are the best

[Jouni Forss · Accepted solution]

Hi,

Glad to hear its working :)

Didnt notice the difference in the name as they looked so same on a quick glance but as I could not find any problem with the configurations in general had to take another look.

Please do remember to mark a reply as the correct answer if it answered your question and/or rate helpfull answers :)

- Jouni