topic Re: Using Loopback interfaces for a site-to-site IPSEC VPN in General Topics

Using Loopback interfaces for a site-to-site IPSEC VPN

merrick — Sun, 20 Sep 2015 02:07:25 GMT

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

Scott

801-545-6674

Re: Using Loopback interfaces for a site-to-site IPSEC VPN

cpainchaud — Sun, 20 Sep 2015 19:03:18 GMT

Hi,

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.

Re: Using Loopback interfaces for a site-to-site IPSEC VPN

santonic — Mon, 21 Sep 2015 08:04:12 GMT

@cpainchaud

I don't see why you shouldn't use loopback interface for IPSEC?

@merrick

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.

Re: Using Loopback interfaces for a site-to-site IPSEC VPN

cpainchaud — Mon, 21 Sep 2015 08:09:16 GMT

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

Re: Using Loopback interfaces for a site-to-site IPSEC VPN

reaper — Mon, 21 Sep 2015 11:29:52 GMT

Hi Merrick

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

regards

Tom

Re: Using Loopback interfaces for a site-to-site IPSEC VPN

pankaku — Mon, 21 Sep 2015 13:51:34 GMT

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

https://live.paloaltonetworks.com/t5/Configuration-Articles/IPSec-Traffic-Being-Discarded/ta-p/57187

Re: Using Loopback interfaces for a site-to-site IPSEC VPN

merrick — Wed, 23 Sep 2015 23:08:35 GMT

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?

Re: Using Loopback interfaces for a site-to-site IPSEC VPN

cpainchaud — Wed, 23 Sep 2015 23:14:14 GMT

keep tunnel in Partners.

Re: Using Loopback interfaces for a site-to-site IPSEC VPN

SharadP — Sat, 22 Jun 2019 11:38:58 GMT

Hi All,

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.

Re: Using Loopback interfaces for a site-to-site IPSEC VPN

reaper — Tue, 25 Jun 2019 13:04:55 GMT

hi @SharadP

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)

Re: Using Loopback interfaces for a site-to-site IPSEC VPN

OtakarKlier — Tue, 25 Jun 2019 14:55:09 GMT

Hello,

For routing I always use OSPF. However static and PBF also work, just keep in mind any failover scenarios, etc.

Regards,

Re: Using Loopback interfaces for a site-to-site IPSEC VPN

ftbaraoidan — Wed, 03 Nov 2021 05:37:52 GMT

Hi All,

I saw this topic interesting and I am planning to use this set up on our current environment. Is it possible to establish a S2S VPN on Palo alto given the following requirements:

Loopback interface - Public IP (/30)

External interface - Private IP (/28, pt to pt IP with ACI)

We will use this setup to reduce the Public IP's to be used since ACI always requires /28 IP.

Re: Using Loopback interfaces for a site-to-site IPSEC VPN

yogesh12345 — Wed, 19 Jul 2023 08:38:43 GMT

Followed this document :- DotW: Using Loopback Interfaces for a Site-to-Site IPSec VPN - Knowledge Base - Palo Alto Networks

But still my tunnel is not coming up. For testing I am having both Wan ips on same subnet. That is why I am using loopback on different zone. Still tunnel is not coming up.

Getting this logs on firewall

2023-07-18 08:57:31.000 -0700 [DEBG]: { 1: }: resend phase1 packet d217dd2b9ccf0efe:0000000000000000, retry 5
2023-07-18 08:57:31.498 -0700 debug: pan_msg_process(daemon/panike_sysd_if.c:2849): iked rcv msg ipsec_sa_handler(14).
2023-07-18 08:57:31.498 -0700 [DEBG]: { 1: 2}: processing acquire for IKEv1
2023-07-18 08:57:31.498 -0700 [DEBG]: encryption(3des)
2023-07-18 08:57:31.498 -0700 [INFO]: { 1: 2}: request for establishing IPsec-SA was queued since phase1 is not mature, state 3
2023-07-18 08:57:31.498 -0700 debug: sysd_msg_send(daemon/panike_sysd_if.c:2487): iked sysd msg enqueue: ipsec_sa_handler
2023-07-18 08:57:44.000 -0700 [PNTF]: { 1: }: ====> PHASE-1 NEGOTIATION FAILED AS INITIATOR, MAIN MODE <====
====> Failed SA: 10.7.7.1[500]-10.44.199.72[500] cookie:d217dd2b9ccf0efe:0000000000000000 <==== Due to timeout.
----------------------------

Re: Using Loopback interfaces for a site-to-site IPSEC VPN

seb_rupik — Wed, 19 Jul 2023 15:31:02 GMT

Hi there,

Can you elaborate on what you mean when you say both WAN IPs are in the same subnet. The firewall and any router for that matter would not allow routed interfaces in the same VRF to exist in the same subnet.

To get this topology to work you need your WAN interfaces in different subnets, and whatever IP address that your loopback is using to be advertised to your WAN peers. This can be tricky if your WAN peers are not configured for dynamic routing updates. You could ask them to statically configure a route towards your loopback, but they would still need to advertise your loopback to their own peers. This is handled automatically when your loopback IP is part of an aggregate address given by your ISP, but becomes problematic when you are trying to convince ISP2 to advertise a /32 which belongs to ISP1 !

If there peering is done across a private network then there should not be a problem with these advertisements.

I wrote a blog post this covers this setup, albeit using separate VRs but that bit can be ignored:

Palo Alto – tunnel VRF with IPSec – CS7 Networks

cheers,

Seb.