VPN tunnel not coming up (IKE)

Started by Seittit, February 08, 2015, 01:25:04 PM

Previous topic - Next topic

Seittit

This time, it is the firewall  :awesome:

Banging my head against the wall, why won't my phase 1 come up?

Quotecsasav1# ping 192.168.255.2
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 192.168.255.2, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 1/1/1 ms
Quotecsasav1# sh run crypto                 
crypto ipsec ikev1 transform-set FirstSet esp-3des esp-md5-hmac
crypto ipsec ikev2 ipsec-proposal sec
protocol esp encryption aes 3des des
protocol esp integrity sha-1
crypto ipsec security-association pmtu-aging infinite
crypto map csasav1-csasav2 1 match address csasav1-csasav2-l2l
crypto map csasav1-csasav2 1 set peer 192.168.255.2
crypto map csasav1-csasav2 1 set ikev1 transform-set FirstSet
crypto map csasav1-csasav2 1 set ikev2 ipsec-proposal sec
crypto map csasav1-csasav2 interface OUTSIDE
crypto ca trustpool policy
crypto ikev2 policy 10
encryption 3des
integrity sha
group 2
prf sha
lifetime seconds 43200
crypto ikev2 enable OUTSIDE
crypto ikev1 enable OUTSIDE
crypto ikev1 policy 10
authentication pre-share
encryption 3des
hash sha
group 2
lifetime 43200
Quotecsasav1# sh run interface
!
interface GigabitEthernet0/0
nameif OUTSIDE
security-level 0
ip address 192.168.255.1 255.255.255.0
!
interface GigabitEthernet0/1
nameif INSIDE
security-level 100
ip address 192.168.100.1 255.255.255.0
!

Quotecsasav1# sh run access-l
access-list csasav1-csasav2-l2l extended permit ip object csasav1-LAN object csasav2-LAN
Quotecsasav1# sh run object
object network csasav1-LAN
subnet 192.168.100.0 255.255.255.0
object network csasav2-LAN
subnet 192.168.200.0 255.255.255.0
csasav1#

NO SA FOUND. WAT.

Quotecsasav1# sh crypto isakmp sa

There are no IKEv1 SAs

There are no IKEv2 SAs
csasav1# sh crypto ipsec sa

There are no ipsec sas
csasav1#

deanwebb

What do the configs look like on the other end?

Did you remember to generate "interesting traffic" that matches the access-list?

What does the debug output look like after generating the "interesting traffic"?
Take a baseball bat and trash all the routers, shout out "IT'S A NETWORK PROBLEM NOW, SUCKERS!" and then peel out of the parking lot in your Ferrari.
"The world could perish if people only worked on things that were easy to handle." -- Vladimir Savchenko
Вопросы есть? Вопросов нет! | BCEB: Belkin Certified Expert Baffler | "Plan B is Plan A with an element of panic." -- John Clarke
Accounting is architecture, remember that!
Air gaps are high-latency Internet connections.

Seittit

debugs show nothing, no traffic.  i'll upload the goodies.

killabee

You're interesting traffic ACL is for traffic from 192.168.100.0/24 to 192.168.200.0/24.....but the traffic you generated on your ping is to 192.168.255.2....Was that ping intended to show us that you generated interesting traffic, or that you can ping the peer?

1. Post a "sh run route" to 192.168.200.0/24 and verify that your ASA knows how to get there.  Verify that the far end knows how to get BACK to 192.168.100.0/24 (assuming you're not doing any NATing)

2. Also, try generating traffic from something in the 192.168.100.0/24 other than your local INSIDE interface.

3. See if the ASA Packet Tracer can tell you what's wrong.

Seittit

Quote from: killabee on February 08, 2015, 10:11:47 PM
You're interesting traffic ACL is for traffic from 192.168.100.0/24 to 192.168.200.0/24.....but the traffic you generated on your ping is to 192.168.255.2....Was that ping intended to show us that you generated interesting traffic, or that you can ping the peer?

You were correct, I was testing basic connectivity between ASA firewalls

Seittit

So here's the short and sweet summary. network topology looks like this:


What's not shown is an out-of-band management interface on all devices, subnet 10.0.1.0/24. I had the ASA firewalls propegate a default-route within their OSPF process facing their directly connected CSR1000v routers.

Where I failed:
I assumed that the 'show isakmp sa' output would reveal the ike policy applied to the interface, even if the tunnel wasn't established
I forgot to share networks between the ASA firewalls, so CSASAv1 had no route to the LAN on CSASAv2 and vice-versa.

Initiating a simple ping between CSR routers after including a static route on both firewalls brought up the IPSEC tunnel.  Thanks for your feedback, I spend so much time in Palo Alto that I forget some basics of the ASA platform.

deanwebb

Yep, a little ping'll do ya, once you set up routing and ACLs and all...
Take a baseball bat and trash all the routers, shout out "IT'S A NETWORK PROBLEM NOW, SUCKERS!" and then peel out of the parking lot in your Ferrari.
"The world could perish if people only worked on things that were easy to handle." -- Vladimir Savchenko
Вопросы есть? Вопросов нет! | BCEB: Belkin Certified Expert Baffler | "Plan B is Plan A with an element of panic." -- John Clarke
Accounting is architecture, remember that!
Air gaps are high-latency Internet connections.

SimonV

Guess it wasn't the firewall after all

:awesome:

killabee

Routing and NATing kicks my ass all the time with VPNs.

fsck

Quote from: killabee on February 09, 2015, 06:51:48 PM
Routing and NATing kicks my ass all the time with VPNs.
Seriously!! Me too! I just had that issue today, trying to get another VPN up