Site to Site IPSec VPN using Loopback as a tunnel endpoint

[turbo_engine26]

Dears,

I've spent two days figuring out how can I use the loopback interface as the tunnel endpoint. After lots of experiments, I could finally get it to work. However, I still don't understand how it completely works. I understand parts of the configuration but other parts I could not understand.

Here is the most important config for a loopback to function as VPN tunnel endpoint along with my humble technical explanation according to my understanding so far. I am not going to mention other config such as IKE/IPSec proposals, IPSec transform sets, interesting traffic ACL...,etc as you already familiar with. Please feel free to correct me if I am wrong.

"Apply crypto map on both the loopback interface and the Ethernet sub-interface. Since the loopback is a virtual interface, it cannot negotiate the tunnel. It's the job of the physical interface, which is the ethernet in my case because it's the actual WAN interface. Applying the map on both of them is crucial. Why I said that? Because if I remove the map off one of them, the tunnel won't negotiate"  

!

Interface Loopback0

Ip address 42.x.x.x 255.255.255.255

Crypto map Mymap

!

Interface ethernet0.156

encapsulation dot1q 156

Ip address 10.x.x.x 255.255.255.252

ip nat outside

ip virtual-reassembly in

Crypto map Mymap

"Because the public IP is defined in the loopback interface, it must be our VPN endpoint. To accomplish this, the following command is important to instruct the router to treat the loopback address as the VPN endpoint. Without it, the router will think that the endpoint address is the physical interface and the tunnel will never negotiate since the public IP is not defined in the physical interface. Why I said that? Because if you issue debug crypto ipsec, you will notice that the other peer will try to negotiate the tunnel with the 42.x.x.x on ethernet0.156 and it will tells you invalid local address."

Crypto map Mymap local-address Loopback0

"Again, the loopback is not a physical interface. It can't forward or route traffic. So, we need to reach the remote protected subnet in order to virtually forward traffic through the Ethernet interface. In that case, Ethernet uses the loopback as a gateway to reach the subnet in question. Why I said that? I really don't know. I am trying my best to explain it. But if you really remove this command, the ping won't work"

Ip route 192.168.0.0 255.255.248.0 Loopback99

"Finally, you will have to exempt the protected traffic from NAT on the loopback"

Ip nat inside source route-map nonat interface Loopback0 overload

!

Route-map permit 10

Match ip address 102

!

Access-list 102 deny ip 10.10.1.0 0.0.0.255 192.168.0.0 0.0.7.255

Access-list 102 permit ip 10.10.1.0 0.0.0.255 any

Thanks

[Karsten Iwen]

Actually, it can be much more simpler then you have done it:

• The crypto map is only applied on the outside interface
• You route your peer-network to the provider next-hop (typically done with the default-route) instead of to the Loopback.
• The crypto-map is told which IP to use for the source-address of the outer tunnel-header (that's the local-address that you configured)
• And you also need to exempt the traffic from NAT

That's all you need. What happens here:

1. The ip packet enters the router and get's forwarded to the outer interface
2. The crypto map acts on the packet and positively matches the crypto ACL
3. The packet gets encrypted and the digest is calculated
4. Now the router builds the outer IP header. The destination is taken from the "set peer", the source is taken from the "local address" (well, that's a little bit simplified, here the SPD and SADB are involved).
5. The new IPsec packet is routed according to the routing table (default-route) to the provider

[turbo_engine26]

Thanks for the response.

"The crypto map is only applied on the outside interface"

The tunnel wouldn't get established if I've done that. I turned on debug crypto isakmp and IPsec and nothing showed up. When I applied the map on both, debug messages showed up.

"You route your peer-network to the provider next-hop (typically done with the default-route) instead of to the Loopback"

There is already a default route through my provider next-hop in general but that didn't serve the purpose of the remote protected network. Once I specifically configured a static route to the remote protected network via Lookback0, I could ping successfully.

[Karsten Iwen]

Could it be that you are running an ancient IOS? I did a short lab on IOS 15.2(4)M5 and it was working exactly like mentioned. And from my memories, that was also the way I implemented it long time ago (but I don't remember what version I used there).

But some time ago, there were changes in IOS when dealing with logical interfaces.

[turbo_engine26]

No sir, it's 15.2 as well. Perhaps, it will work using different methods. :)

Anyways, thanks for your help.

[Karsten Iwen]

Can you show the config for that? Perhaps there is something else problematic.

[turbo_engine26]

I showed the config in the original post.

[Karsten Iwen]

I assume that was not the real config as it was configured on the router ...

[turbo_engine26]

It was the real config but of course with fake IP addressing, that's all. I mentioned in the original post that I got the VPN to work using loopback interface then I posted the working config.

[faridpangos]

After I saw this tread I went even deeper. I did this but with dual links. And there is an issue with IP cef. Not sure if this is normal behavior. I running IOL not tried with physical devices yet but here we go: 

R1 is the local source endpoint for the tunnel. Crypto map applied to e0/2.

Remote endpoint of R1 is e0/2 of R2

To route to e0/2 ip address is directed connected.

The way back is key here. I routed with static router on R2 so it goes through down to R5. So there is asymetric routing

Interesting. IKEV1 phase is routed correctly but ESP traffic is not.

For some reason ESP traffic , the outer layer, does not route from R1 to R2 but instead it Routes down to R5.

I was debuggin ip packets as I thought locally generated is process switched and not ip cef switched. 

As soon as I disable ip cef ESP traffic routes the same way ISAKMP did and everthing works fine. 

[Gerardo Marciales]

Thanks for sharing, it worked to me. I did not exactly the same, but your post was a hint.

Best.

[tharaka3000]

Hi, Can you please let me know what is configured under Loopback99? you have used this in the static routing.

[ahmed.mamoon]

Hi,

I think I am quite late on replying to this.

However just define a loopback e.g. loopback 20

Assign a public IP to it or whatever IP you want to source the VPN Traffic from.

And use the below command.

crypto map CMAP local-address Loopback20

Then create a Crypto MAP after creating the Transform Set and interesting traffic access-list.

              crypto map CMAP 10 ipsec-isakmp
              set peer 10.172.16.1
              set transform-set TS
              match address VPN-TRAFFIC

Create preshared key for the destination peer like below

              crypto isakmp key firewallcx address 10.172.16.1

Do the same config on the other peer and you are good to do.

Let me know if someone wants me to share the complete config.

[new_cisco_learner]

Please share me the complete configuration file.

[ahmed.mamoon]

Hi,

Its been an year and I don't have the config on me anymore. However below is what i used as a template and incorporated my own config into it and I am sure you can also do the same. 

http://www.firewall.cx/cisco-technical-knowledgebase/cisco-routers/867-cisco-router-site-to-site-ipsec-vpn.html

Cheers,