cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
2224
Views
0
Helpful
6
Replies

IPSEC tunnel - remote and local network specifications

matthewceroni
Level 1
Level 1

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

6 Replies 6

Jouni Forss
VIP Alumni
VIP Alumni

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

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

matthewceroni
Level 1
Level 1

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).

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

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.

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

Getting Started

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: