Solved: ASA as l2l terminaison point and route between remote peers

FlorianBerthelot · ‎01-06-2014

Hi dear support community,

I need to setup the following scenario :

I managed to create the tunnels from routers to ASA but there are 2 issues :

From remote LANs i am not able to ping the inside interface, apart if i use the management-access command on my inside interface, thing that i dont want.
Remote LANs cannot communicate with each other. Is there some routing i should add ? My Inside Interface has a temporary permit icmp any any, and i guess that the ASA should bring up the appropriate routes when tunnels comes up. I have identfyed the routes correctly in my Crypto map and on my remote routers.

As my remote routers all have dynamic assigned IP adresses they all fall into the defaultl2l Tunnel group. Is this wrong ?

Any ideas or suggestions would be extremely appreciated

Thank you for your help !

Jouni Forss · ‎01-06-2014

Hi,

The ASAs in general have a limitation that you can't ICMP/PING an interface from behind another interface of the ASA. The command "management-access " is the only way to enable ICMP the interface through another interface. And furthermore this only applies to connections that are coming through a VPN connection.

So if you want to ICMP/PING the "inside" interface of the ASA from the remote sites you will have to use the "management-access" command. If the management connections are your worry then you should limit the management so that the remote networks will not be able to manage the ASA. Naturally they would also need to know the login information to even have the chance to manage the ASA?

As to your other question, there are some things that you need to make the connections work between the remote LANs if you plan to do this through the central site with the ASA.

You will need to have the command "same-security-traffic permit intra-interface" configured on the ASA. This command will enable traffic to enter and leave the same interface on the ASA. In your case this would be the "outside" interface which would be the only interface through which the traffic between the remote LANs would traverse through the ASA
You will need to define the interesting traffic on the L2L VPN connections so that it includes this traffic
- L2L VPN connection from ASA to a remote site VPN device needs to has as its source address for interesting traffic the other remote sites network.
- L2L VPN connection from the remote VPN device will have to have as destination address the other remote network
You will have to have NAT0 configurations for the traffic on the remote site VPN devices
You will have to have NAT0 configurations on the ASA for this traffic that is going to flow between the remote sites through the ASA. This NAT0 configurations will have to be configured on the "outside" interface. The configuration format naturally depends on your ASA software level

Though you mention that you are using a default L2L VPN "tunnel-group" for both of the connections.

I would suggest looking at this document. It would enable you to configure the remote sites so that you could configure separate "tunnel-group" for them on the ASA and accomplish what you want.

http://www.cisco.com/en/US/products/ps6120/products_tech_note09186a0080bc7d13.shtml

Hope this helps

- Jouni

View solution in original post

Jouni Forss · ‎01-06-2014

Hi,

The ASAs in general have a limitation that you can't ICMP/PING an interface from behind another interface of the ASA. The command "management-access " is the only way to enable ICMP the interface through another interface. And furthermore this only applies to connections that are coming through a VPN connection.

So if you want to ICMP/PING the "inside" interface of the ASA from the remote sites you will have to use the "management-access" command. If the management connections are your worry then you should limit the management so that the remote networks will not be able to manage the ASA. Naturally they would also need to know the login information to even have the chance to manage the ASA?

As to your other question, there are some things that you need to make the connections work between the remote LANs if you plan to do this through the central site with the ASA.

You will need to have the command "same-security-traffic permit intra-interface" configured on the ASA. This command will enable traffic to enter and leave the same interface on the ASA. In your case this would be the "outside" interface which would be the only interface through which the traffic between the remote LANs would traverse through the ASA
You will need to define the interesting traffic on the L2L VPN connections so that it includes this traffic
- L2L VPN connection from ASA to a remote site VPN device needs to has as its source address for interesting traffic the other remote sites network.
- L2L VPN connection from the remote VPN device will have to have as destination address the other remote network
You will have to have NAT0 configurations for the traffic on the remote site VPN devices
You will have to have NAT0 configurations on the ASA for this traffic that is going to flow between the remote sites through the ASA. This NAT0 configurations will have to be configured on the "outside" interface. The configuration format naturally depends on your ASA software level

Though you mention that you are using a default L2L VPN "tunnel-group" for both of the connections.

I would suggest looking at this document. It would enable you to configure the remote sites so that you could configure separate "tunnel-group" for them on the ASA and accomplish what you want.

http://www.cisco.com/en/US/products/ps6120/products_tech_note09186a0080bc7d13.shtml

Hope this helps

- Jouni

FlorianBerthelot · ‎01-07-2014

Hi Jouni,

thanks for the guidelines, unfortunately we did not manage to make it work, all tunnels set up fine in a different tunnel-group (thanks to your recommandations !) but no way to make the remote LAN communicate.

Even with the NAT 0 (im using 8.4 so this is slightly different command).

I dont understand why such simple scenario is so complicated to implement on the ASA

I have identifyed traffic from site A to site B, site B to site A, configured the same-security-traffic permit intra-interface

The remote routers have the correct routes for traffic to be sent to the VPN...

And still no go, and there is no easy way to troubleshoot.

I will see other solutions to set-up such scenario.

Best regards

Jouni Forss · ‎01-07-2014

Hi,

So have you confirmed that the IPsec SAs form on both L2L VPN connections for the traffic from Remote to Remote?

I would first confirm that you can see the L2L VPN negotiated up for those remote network on both L2L VPN and then check the traffic counters on the VPN to determine if the traffic stops at a certain location.

I can only guess to the reason of the problem without seeing configurations.

Do you have the following NAT0 configuration on the ASA for the Remote to Remote traffic

object network REMOTE-LAN-1

subnet 192.168.252.0 255.255.255.0

object network REMOTE-LAN-2

subnet 192.168.242.0 255.255.255.0

nat (outside,outside) 1 source static REMOTE-LAN-1 REMOTE-LAN-1 destination static REMOTE-LAN-2 REMOTE-LAN-2

We can get some output during traffic/connection tests to try determine the problem with the current setup

- Jouni

FlorianBerthelot · ‎01-08-2014

Hi Jouni,

thanks very much for your implication on this topic !

Here is my configuration :

## definition of network objects

object network CIPAC-ENERGY-VALE

subnet 192.168.250.0 255.255.255.0

object network CIPAC-ENERGY-VALE-POMPE1

subnet 192.168.242.0 255.255.255.0

object network CIPAC-ENERGY-VALE-POMPE2

subnet 192.168.252.0 255.255.255.0

## tunnel towards POMPE1

access-list OPT_cryptomap_65535.120 extended permit ip object CIPAC-ENERGY-VALE object CIPAC-ENERGY-VALE-POMPE1

access-list OPT_cryptomap_65535.120 extended permit ip object CIPAC-ENERGY-VALE-POMPE2 object CIPAC-ENERGY-VALE-POMPE1

## tunnel towards POMPE2

access-list OPT_cryptomap_65535.121 extended permit ip object CIPAC-ENERGY-VALE object CIPAC-ENERGY-VALE-POMPE2

access-list OPT_cryptomap_65535.121 extended permit ip object CIPAC-ENERGY-VALE-POMPE1 object CIPAC-ENERGY-VALE-POMPE2

## tunnel group for POMPE1

tunnel-group CLT-CIPACENERGY-VALE-POMPE1 type ipsec-l2l

tunnel-group CLT-CIPACENERGY-VALE-POMPE1 general-attributes

default-group-policy CLT_CIPACENERGY_GroupPolicy

tunnel-group CLT-CIPACENERGY-VALE-POMPE1 ipsec-attributes

ikev1 pre-shared-key blablabla

peer-id-validate nocheck

## tunnel group for POMPE2

tunnel-group CLT-CIPACENERGY-VALE-POMPE2 type ipsec-l2l

tunnel-group CLT-CIPACENERGY-VALE-POMPE2 general-attributes

default-group-policy CLT_CIPACENERGY_GroupPolicy

tunnel-group CLT-CIPACENERGY-VALE-POMPE2 ipsec-attributes

ikev1 pre-shared-key blablabla

peer-id-validate nocheck

!

## nat to allow remote sites to reach each others

nat (OUTSIDE,OUTSIDE) source static CIPAC-ENERGY-VALE-POMPE1 CIPAC-ENERGY-VALE-POMPE1 destination static CIPAC-ENERGY-VALE-POMPE2 CIPAC-ENERGY-VALE-POMPE2

## routes on remote sites :

POMPE1

S~ 192.168.250.0/ 255.255.255.0 via 202.XXX.YYY.ZZZ VPN-1

S~ 192.168.252.0/ 255.255.255.0 via 202.XXX.YYY.ZZZ VPN-1

C~ 192.168.242.0/ 255.255.255.0 directly connected LAN

POMPE2

S~ 192.168.250.0/ 255.255.255.0 via 202.XXX.YYY.ZZZ VPN-1

C~ 192.168.252.0/ 255.255.255.0 directly connected LAN

S~ 192.168.242.0/ 255.255.255.0 via 202.XXX.YYY.ZZZ VPN-1

This seems to be very correct to me, correct me if there are some mistakes.

However, as i am using the ASDM, i just saw that both tunnel-groups are using the

default-group-policy CLT_CIPACENERGY_GroupPolicy that i have defined :

group-policy CLT_CIPACENERGY_GroupPolicy internal
group-policy CLT_CIPACENERGY_GroupPolicy attributes
 vpn-tunnel-protocol ikev1 
!

Can the group-policy affect my configuration ? here the default

group-policy DfltGrpPolicy attributes
 dns-server value 172.16.xx.yy 172.16.xx.yy
 vpn-tunnel-protocol ikev1 l2tp-ipsec ssl-client ssl-clientless
 default-domain value mydomain.local

Thanks a lot for your valuable feedback !

Jouni Forss · ‎01-09-2014

Hi,

The "group-policy" configuration used is ok. It should cause no problems.

I would still check the different outputs when trying to test the connectivity between the remote sites.

show crypto ipsec sa

You could also check the central ASA with the command

show nat detail

and see if there is anything matching the NAT configuration built to enable the traffic between the 2 remote sites.

It would be good to first determine that if the traffic is generated from the remote site to the other that the L2L VPN towards the central ASA goes up. This could be tested from both remote sites.

- Jouni

FlorianBerthelot · ‎01-09-2014

Hello Jouni,

thanks again for your pieces of information. I have identified the issue :

ASA001# sho crypto ipsec sa peer 180.214.XXX.YYY

peer address: 180.214.XXX.YYY

Crypto map tag: SYSTEM_DEFAULT_CRYPTO_MAP, seq num: 120, local addr: 202.171.XXX.YYY

access-list OPT_cryptomap_65535.120 extended permit ip 192.168.250.0 255.255.255.0 192.168.242.0 255.255.255.0

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

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

current_peer: 180.214.XXX.YYY

#pkts encaps: 4, #pkts encrypt: 4, #pkts digest: 4

#pkts decaps: 20, #pkts decrypt: 4, #pkts verify: 4

#pkts compressed: 0, #pkts decompressed: 0

#pkts not compressed: 4, #pkts comp failed: 0, #pkts decomp failed: 0

#pre-frag successes: 0, #pre-frag failures: 0, #fragments created: 0

#PMTUs sent: 0, #PMTUs rcvd: 0, #decapsulated frgs needing reassembly: 0

#send errors: 0, #recv errors: 16

BUT my access list contains those 2 lines wich identify the traffic :

DSPREASA001# sh run | inc access-list OPT_cryptomap_65535.120

access-list OPT_cryptomap_65535.120 extended permit ip object CIPAC-ENERGY-VALE-POMPE2 object CIPAC-ENERGY-VALE-POMPE1

access-list OPT_cryptomap_65535.120 extended permit ip object CIPAC-ENERGY-VALE object CIPAC-ENERGY-VALE-POMPE1

And effectively the traffic is dropped when try to reach the other remote LAN :

4 Jan 10 2014 11:28:34 402116 180.214.XXX.YYY 202.171.XXX.YYY IPSEC: Received an ESP packet (SPI= 0xAA87A3E3, sequence number= 0x9) from 180.214.XXX.YYY (user= CLT-CIPACENERGY-VALE-POMPE1) to 202.171.XXX.YYY. The decapsulated inner packet doesn't match the negotiated policy in the SA. The packet specifies its destination as 192.168.252.254, its source as 192.168.242.11, and its protocol as icmp. The SA specifies its local proxy as 192.168.250.0/255.255.255.0/ip/0 and its remote_proxy as 192.168.242.0/255.255.255.0/ip/0.

Funny thing is that if i change the order of ACLs on the remote router then i am able to reach the other remote LAN but no the ASA... looks too weird to me, I'm going thru support team.

I will keep you updated,

best regards,

Florian