01-06-2014 04:44 PM
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 :
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 !
Solved! Go to Solution.
01-06-2014 04:58 PM
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
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.
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
01-06-2014 04:58 PM
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
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.
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
01-07-2014 05:15 PM
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
01-07-2014 11:49 PM
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
01-08-2014 03:15 PM
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 !
01-09-2014 07:25 AM
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
01-09-2014 06:50 PM
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
Discover and save your favorite ideas. Come back to expert answers, step-by-step guides, recent topics, and more.
New here? Get started with these tips. How to use Community New member guide