Does anybody have experience configuring site-to-site IPSEC VPNs using loopback interfaces instead of phsical ones? If you are going to respond with a sassy comment (e.g. Why are you doing that? or That's dumb!) then please don't respond. I have a specific need. I have the VPN setup. I can send traffic to the remote end, but it appears that the firewall drops the returning ESP packets upon return. I don't see that in the logs, but rather when performing a network capture within the firewall. The firewall records the returning ESP packets in the receive and drop logs. I've been busting my head trying to figure this one out along with others in my circle, but we just can seem to crack this baby.
I will be happy to share my config, or perform a web-ex with you in order to get to the bottom of this.
Your assistance in appreciated...
you need to ensure that your loopback is in same zone than the external interface.
Anyway, this is not a supported design and I know TAC may refuse to support it. I have seen issues as well.
I don't see why you shouldn't use loopback interface for IPSEC?
Usual when the packets aren't forwarded and there is nothing in logs it's a routing issue. So I'd suggest to check routing. Maybe the rule is written to forward packets to an interface instead of IP address?
Also if you're behind NAT check if there's a NAT rule for 'any' service as ESP can't be NAT-ed specifically.
@santonic because my experiences over 5 years on the product instructs that there are issues and also because I am 90% sure TAC will say it is not supported as they did for 2 of my customers.
could you provide some more information regarding your config? There are several different ways to configure ipsec on a loopback interface, having some insight into how you set it up may help: is there NAT, which zones are being used, how did you configure the ike gateway objects ...
In general it would be recommended to set the loopback in the external zone and assign it a public IP, this will make for the least complexity as NAT and different zones could require complex policies depending on your overal design plus some options may not be available
Put the loopback in same zone as that of physical interface zone. That will work.
There is a KB article for that as well.
Here is the doc
So I have a zone called PARTNERS which is where my current loopback and tunnel interface are configured. If I change the loopback to the UNTRUST zone (to the Internet), then do I need to move my tunnel interface to that zone as well? I would like to write rules in which the source zone would be PARTNERS as this connection is with a business partner. What do I need to do in this case?
was going through this thread as i have a similar issue which is -
# client has 3 different internet links terminated on 3 different ASA firewalls which i have consolidated into 1 Internet Vsys.
# Now using 3 Loopback interfaces to terminate Site-Site VPNs. All 3 have different public ip addresses.
# Loopback interfaces are in "internet zone", tunnel interfaces are in a separate "VPN zone".
# VPN zone to trust zone policy is their.
My questions -
1. I have 100+ tunnel interfaces, assigning specific routes with tunnel interface is the only option their ?
2. Do i need to put an "internet zone" to "vpn zone" policy ? i think its not required.
Any help is much appreciated.
1. yes, you'll need to route somehow (someone may have an elegant dynamic routing solution?)
2. no, the vpn zone does not need to talk to your internet zone, unless you want to route traffic out to the internet (eg if a remote site must come through the main site for internet access)
Click Accept as Solution to acknowledge that the answer to your question has been provided.
The button appears next to the replies on topics you’ve started. The member who gave the solution and all future visitors to this topic will appreciate it!
These simple actions take just seconds of your time, but go a long way in showing appreciation for community members and the LIVEcommunity as a whole!
The LIVEcommunity thanks you for your participation!