How does a packet know the return route through a L2L VPN?

[jmaxwellUSAF]

How does a packet know the return route through a L2L VPN?

Thank you.

[Rob Ingram]

@jmaxwellUSAF in a policy based VPN, traffic is routed from the core switch to the ASA, then routed to the egress interface, if traffic explictly matches the crypto ACL it is encrypted and routed through the VPN tunnel. The same would apply to the remote peer for the return traffic.

If using a route based VPN, then traffic must be routed (static or dynamically) through the specific VTI (virtual tunnel interface), therefore the remote peer must also do the same for the return trafffic.

[jmaxwellUSAF]

Thank you Rob.

Your help guided me to find this helpful explanation--  Policy based vs Route based VPN's - Which one to use - IPSec tutorial Guide (internet-computer-security.com)
And this is what i needed to know...
"A route based VPN is required when there is a requirement for redundant VPN connections, or there is a need for dynamic routing within a VPN tunnel. A route based VPN only works in route (layer 3) mode, where policy based VPN works in both route and transparent mode, and a policy based VPN is simpler to create."

OK, my VPN is a "redundant VPN connection." I will now proceed with "route based VPN" routing strategy / configuration.

May you please tell me if my already active tunnel (config below) needs to be reconfigured? 

(I need to ask a 2nd question regarding this. I will do that in the following post.)

Thank you!

---

3. Set tunnel group and tunnel type
#tunnel-group 2.2.2.2 type ipsec-l2l
#tunnel group 2.2.2.2 ipsec-attributes
#ikev2 local-authentication pre-shared-key ObFuScAtEd
#ikev2 remote-authentication pre-shared-key ObFuScAtEd

4. Define the IPsec policy
#crypto ipsec ikev2 ipsec-proposal VENDOR-PROPOSAL-1
#protocol esp encryption aes-256
#protocol esp integrity sha-512

5. Append the existing crypto map ACL
#access-list VENDOR-Cryptomap-ACL remark >>ACL REFERENCED BY CRYPTO-MAP<<
#access-list VENDOR-Cryptomap-ACL extended permit ip 172.16.80.0 255.255.255.0 172.16.30.0 255.255.255.0

6. Configure the crypto map.
#crypto map VENDOR-cryptomap-1 interface outside1
#crypto map VENDOR-cryptomap-1 1 match address VENDOR-Cryptomap-ACL
#crypto map VENDOR-cryptomap-1 1 set peer 2.2.2.2
#crypto map VENDOR-cryptomap-1 1 set ikev2 ipsec-proposal VENDOR-PROPOSAL-1

7. Bypass NAT
#object network MY-LAN-NETWORK-1
#subnet 172.16.80.0 255.255.255.0
#object network VENDOR-LAN-NETWORK-1
#subnet 172.16.30.0 255.255.255.0
#exit
#nat (inside,outside1) source static MY-LAN-NETWORK-1 MY-LAN-NETWORK-1 destination static VENDOR-LAN-NETWORK-1 VENDOR-LAN-NETWORK-1

8. Configure Internal Group Policy & attributes.
#group-policy 2.2.2.2 internal
#group-policy 2.2.2.2 attributes
#vpn-tunnel-protocol ikev2
#pfs enable

==========

[Rob Ingram]

@jmaxwellUSAF if you wish to use a route based VPN, then you will need to configure a VTI, IPSec Profile and routing (static or dynamic) - this example shows you the configuration of a VTI https://integratingit.wordpress.com/2018/06/09/configuring-a-vti-tunnel-between-asa-firewall-and-ios-router/

[jmaxwellUSAF]

OK. So my enterprise and vendor1 already have an active effective VPN. This project was to implement a second VPN through a different location within our enterprise, which will permit both redundancy and load balancing.

Is the config listed above useless for this project?

[jmaxwellUSAF]

GIVEN:
1. VENDOR1 is gently refusing to tell me if his server endpoints live in the crypto-ACL-defined remote subnet 172.16.30.0/24

2. The VPN terminates at my local subnet 172.16.80.0. My servers live at subnet 172.16.90.0/24

Questions:
1. Will below config implement successful routing connectivity between my servers and this VPN?

2. If above answer is "no", may you please adjust the config?

3. If VENDOR1 remote servers DO NOT live at 172.16.30.0/24, but deeper in VENDOR 1 LAN, will this config fail?

Thank you!
---

prefix-list VPN-NETWORKS-1 seq 10 permit 172.16.90.0/24 !! should this be 80 ? !!
route-map VPN-ROUTES-1 permit 10
    match ip address prefix-list VPN-NETWORKS-1
router eigrp 1
    redistribute static subnets route-map VPN-ROUTES-1
crypto map VENDOR1-cryptomap-1 1 set reverse-route dynamic

[Rob Ingram]

@jmaxwellUSAF You've got a policy based VPN, the crypto map ACL will permit traffic from your network 172.16.80.0/24 to destination 172.16.30.0/24. So if your network is actually 172.16.90.0/24 then you'll either need to add another ACE to your crypto ACL "VENDOR-Cryptomap-ACL" (as will the 3rd party)

access-list VENDOR-Cryptomap-ACL extended permit ip 172.16.90.0 255.255.255.0 172.16.30.0 255.255.255.0

or NAT traffic from 172.16.90.0/24 to 172.16.80.x
or change to a route based VPN and just advertised routes over the network (probably unlikely as it's a third party VPN)

I don't know if you are getting confused about the RRI configuration, that's only relevant to advertise the peer's VPN networks into the routing table of your adjacent devices.

[jmaxwellUSAF]

So all I need to do to accomplish the task of implementing a second VPN through a different location within our enterprise, which will permit both redundancy and load balancing, is simply to add to the existing config...

access-list VENDOR-Cryptomap-ACL extended permit ip 172.16.90.0 255.255.255.0 172.16.30.0 255.255.255.0 ,

and have him do similar on his end,

1. ...And that's it?

2. Is it best to erase the old...
"access-list VENDOR-Cryptomap-ACL extended permit ip 172.16.80.0 255.255.255.0 172.16.30.0 255.255.255.0" ?

Thank you Rob!

BTW, this message board is definitely more effective than TAC tickets. You guys definitely know more than the average TAC tech.

[Rob Ingram]

@jmaxwellUSAF I'd not read your other message...."OK. So my enterprise and vendor1 already have an active effective VPN. This project was to implement a second VPN through a different location within our enterprise, which will permit both redundancy and load balancing."......when I replied to the last email, so I'd not seen the requirement for redundancy and load balancing.

The previous suggestion to modify the crypto ACL would allow traffic from 172.16.90.0/24 to the peer to be encrypted over the existing tunnel. If you want to permit redundancy and load balancing then there is more complexity to that.

If you wanted to continue with your policy based VPN, this is where RRI could come in and advertise those remote networks (172.16.30.0/24) via ASA1 (when the VPN is UP) to your core switch. If that VPN dies those routes disappear from your core switch, then take another route (could be a weighted static) via your other ASA. The 3rd party would need to redesign their configuration to define multiple peers. So if the primary peer dies, establish a tunnel to the other peer.

An example of the policy based VPN design I am thinking of - https://integratingit.wordpress.com/2020/05/21/asa-multi-peer-vpn/

For load balancing you'd need the 3rd party to redesign their configuration to load balance the traffic to you, there is probably more complexity doing this, may not be worth it.

[Rob Ingram]

For load balancing you'd need the 3rd party to redesign their configuration to load balance the traffic to you, there is probably more complexity doing this, may not be worth it.

[jmaxwellUSAF]

OK, let's forget the load balancing.

1. Will the below addition to the existing config establish communication between the local and tunneled remote endpoints?...

#access-list VENDOR-Cryptomap-ACL extended permit ip 172.16.90.0 255.255.255.0 172.16.30.0 255.255.255.0 ,
!! vendor adds similar above config on his end. Then... !!
#prefix-list VPN-NETWORKS-1 seq 10 permit 172.16.90.0  255.255.255.0
#route-map VPN-ROUTES-1 permit 10
    #match ip address prefix-list VPN-NETWORKS-1
#router eigrp 1
    #redistribute static subnets route-map VPN-ROUTES-1
#crypto map VENDOR1-cryptomap-1 1 set reverse-route dynamic

2. Is it best to erase the old...
"access-list VENDOR-Cryptomap-ACL extended permit ip 172.16.80.0 255.255.255.0 172.16.30.0 255.255.255.0" ?

Thank you.

[Rob Ingram]

@jmaxwellUSAF one of us is getting confused.

You have a policy based VPN, so you aren't sending any routes to the peer via EIGRP over the VPN. The RRI is used to redistribute the peer's networks into EIGRP, not your own.

Do you want to provide a topology diagram and re-state your intention.

[jmaxwellUSAF]

The tunnel is up and active. The servers presently cannot communicate. I need the servers to communicate.

May you please assist?

Thank you.

[Rob Ingram]

@jmaxwellUSAF so I assume you mean you are doing this via the existing tunnel?

Have you asked the 3rd party to change their crypto ACL to include 172.16.90.0/24 and have you modified your crypto ACL to do the same?

access-list VENDOR-Cryptomap-ACL extended permit ip 172.16.90.0 255.255.255.0 172.16.30.0 255.255.255.0

If not, have you created a NAT rule to translate the 172.16.90.0/24 traffic behind an IP address that is included in the crypto ACL?

If the tunnel is up and active, what is the output of "show crypto ipsec sa"? Is traffic encrypted|decrypted?

[jmaxwellUSAF]

OK, maybe I'm understanding my essential misunderstanding (maybe not) -- 

Please tell me-- What is the definition of the tunnel source / destination endpoints-- are these the public IPs or the LAN IPs?

My whole config is currently set up so that the tunnel "ends" on the inside (LAN) interface of the ASA= 172.16.80.1/24

Are you telling me that my whole config should ignore this ASA inside interface, but instead reflect the downstream device subnet 172.16.90.0/24 ?

Thank you.

[Rob Ingram · Accepted solution]

@jmaxwellUSAF the tunnel source is your outside interface, that face's the internet or WAN. The tunnel destination is the peer ip address as defined in the crypto map (2.2.2.1 in your example).

Encrypted traffic is the networks defined in the ACL. So you need to add another ACE from source 172.26.90.0/24.

You don't need to define the ASA inside interface in the crypto ACL if no traffic sent over the tunnel will be sourced from it.

"Show crypto ipsec sa" will confirm what is currently established for the working existing tunnel.