05-24-2013 12:08 PM - edited 02-21-2020 06:55 PM
I am replacing an ASA at site A with an update one. ASA at site B (which eventually needs to be updated as well) is running version 7.1.1. New ASA is running 9.1.2.
With 7.1.1 you should only specify network objects as a single host IP or subnet. Whereas you now have a range option with the new ASA.
Site B ASA connects to many many customer VPNs. Unfortunately (before my time) we didn't mandate any organization on our customers and the IP addresses on their side of the tunnel are all over the place. Therefore when creating the network objects and network object groups we essentially created a network object per host and then added them to a group (group per customer). These leads to very large and messy network objects/groups.
As an example: customer 1, the IP addresses part of that tunnel are
172.22.89.102
172.22.89.103
172.22.89.104
172.22.89.108
172.22.50.32
172.22.50.33
172.22.64.40
172.22.64.56
So in this case there were 8 network objects created and then added to a network object group for this customer.
When building the new ASA I thought this was an opportunity to clean this up a bit and use the range option. That way I could clump 172.22.89.102 - 172.22.89.108 into one object, and so forth.
I find this works sometimes and not others (I get an invalid ID info (18)) error when doing phase 2, which usually means the remote / local are not mirrors of each other.
So I guess the question is, can I clump consecutive ranges together on one side of the ASA whereas on the other side of the ASA they would be specified individually? What about ranges that may not be 100% consecutive. So in the example above on the new ASA I would create a network object with range 172.22.89.102 - 172.22.89.108 but on the old ASA side it would only list the 4 hosts individually?
Thanks
05-24-2013 12:19 PM
Hi,
We have usually asked the remote end to specify complete subnets that we can use in the L2L VPN configurations. But as you said you had chance to affect this kind of decision when the connections were configured.
What I do wonder is that why would you have "object network" for each host IP address and then have them under "object-group network"?
object-group network L2LVPN-X-REMOTE-NETs
description L2LVPN X Remote Networks
network-object host 172.22.89.102
network-object host 172.22.89.103
network-object host 172.22.89.104
network-object host 172.22.89.108
network-object host 172.22.50.32
network-object host 172.22.50.33
network-object host 172.22.64.40
network-object host 172.22.64.56
I would rather just configure all the host IP addresses under the single "object-group network" wihtout using any "object network".
I have to admit that I have never used or even considered using "object network" and "range" to configure L2L VPN ACLs. I would imagine it can cause problems with the L2L VPN as you say. I rather keep the ACLs exact mirror images of eachother to avoid any problems.
I cant say if using the "range" with IP addresses that arent part of the L2L VPN could be a problem but it sure seems like taking a risk.
I guess I could test this at some point to see what a pair of ASAs with L2L VPN would "think about" having "object network" with "range" configured in the ACLs.
- Jouni
05-24-2013 12:24 PM
As for your question of just creating an object-group network with all hosts under it. That is what we do. I mis-spoke previously. It just gets unweidly having all those network-object hosts.
Thanks
05-27-2013 02:37 PM
Follow-up on this, just trying to expand my knowledge when it comes to IPSec tunnels.
I have seen a few tunnels where the remote and local address specifications match exactly what is in the crypto maps (if you edit the remote and local address for the connection profile it automatically updates the crypto map for you), and I have seen some where the remote and local address setting is a small subset of what is in the crypto map.
From what I have read the remote and local address is used to calculate some ID used in phase 2. So it doesn't really control what traffic can flow through that tunnel (that is the crypto maps job).
05-27-2013 02:42 PM
Hi,
I am not sure I follow.
The only place where the local and remote networks are configured related to the actual VPN is the crypto map.
Other than that, there is usually NAT0 configurations that usually use the complete match of the VPN traffic matching ACL.
- Jouni
05-27-2013 06:29 PM
Hmm. Interesting, I was looking through the configuration and as you stated I didn't see anywhere where the remote and local networks were set.
However I have a tunnel that is setup, and if I look at the connection profile, the remote and local address contain just two address ranges, remote: 192.168.10.0/24 and local: 192.168.2.0/24. However the crypto map for that tunnel contains many other mappings.
Is it just that the remote and local address setting in the connection profile just aids in setting the crypto map? But since they are now out of sync I am wondering where it stores the value for the remote and local address.
By the way this is for ASA 8.2.1.
05-27-2013 11:22 PM
Hi,
I dont usually configure VPN connections through ASDM so my view of the configurations is a bit different than yours.
But basically if I were to configure a new L2L VPN and define the local and remote network I would do the following
access-list L2LVPN remark L2L VPN Encryption Domain
access-list L2LVPN permit ip 10.10.10.0 255.255.255.0 10.10.20.0 255.255.255.0
crypto map CRYPTOMAP 10 match address L2LVPN
Naturally this is only a small part of the configuration but the above commands define what traffic should be tunneled. The ASA would expect that a local network 10.10.10.0/24 will be connecting to 10.10.20.0/24 using the L2L VPN we are configuring.
There is no other place in the actual VPN configuration where we tell the device the local/remote networks. Naturally as I said the NAT configurations usually in the case of NAT0 match the crypto map ACL
In this case it might be
access-list INSIDE-NAT0 remark NAT0 for L2LVPN
access-list INSIDE-NAT0 permit ip 10.10.10.0 255.255.255.0 10.10.20.0 255.255.255.0
nat (inside) 0 access-list INSIDE-NAT0
To fill the Crypto map with the minimum information required to make it complete we might add these configurations for example
crypto ipsec transform-set ESP-AES-256-SHA esp-aes-256 esp-sha-hmac
crypto map CRYPTOMAP 10 set peer 1.1.1.1
crypto map CRYPTOMAP 10 set transform-set ESP-AES-256-SHA
crypto map CRYPTOMAP interface outside
tunnel-group 1.1.1.1 type ipsec-l2l
tunnel-group 1.1.1.1 ipsec-attributes
pre-shared-key test
crypto isakmp enable outside
crypto isakmp policy 10
authentication pre-share
encryption aes-256
hash sha
group 2
lifetime 28800
Whole configurations naturally depend what the device has been previously configured. For example Crypto Map doesnt have to be attached to the interface if you already have an existing one. In that case you just add another connection with another priority/order/sequence number to the list.
- Jouni
Find answers to your questions by entering keywords or phrases in the Search bar above. New here? Use these resources to familiarize yourself with the community: