Bind multiple VPNs to a single tunnel interface?

cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 
Announcements
Please sign in to see details of an important advisory in our Customer Advisories area.

Bind multiple VPNs to a single tunnel interface?

L0 Member

greetings all,

I come from a ScreenOS background, and in their world, you can terminate multiple route-based VPNs onto a single logical tunnel interface.

We have 30-40 remote sites with VPN tunnels back to HQ, which will soon be a new PAN firewall.  In our lab I have tried to configure multiple IPSec VPNs terminating onto the same tunnel interface and I get the following error:

Tunnel interface tunnel.1 multiple binding with different IKE gateways.

This leads me to believe I will have to create a tunnel interface per each remote site -- is this the case?  or is there a configuration setting I am missing that will allow this configuration?

If it is the case, i'm a little worried about having to run a routing protocol on each and every one of those interfaces (we need to dynamically learn routes from the remote sites in our scenario)

Thanks,

Will

1 accepted solution

Accepted Solutions

L3 Networker

Hello,

Yes, you can bind multiple VPNs to an interface.  It would be best to have a zone specified to a tunnel interface so to be able to create separate VPN policies.  Heres a doc for configuring IPSEC VPN:  https://live.paloaltonetworks.com/docs/DOC-1163

View solution in original post

8 REPLIES 8

L3 Networker

Hello,

Yes, you can bind multiple VPNs to an interface.  It would be best to have a zone specified to a tunnel interface so to be able to create separate VPN policies.  Heres a doc for configuring IPSEC VPN:  https://live.paloaltonetworks.com/docs/DOC-1163

Palo Alto Networks Guru

Hi Will,

We do support adding multiple phase 2's to a single tunnel interface.  However your question is specific to phase 1's or IKE gateway configurations.  For this you will need an additional tunnel interface for each site to which you want to connect.

Thanks,

Nick

Hi Nick,

I have the same issue where I can't bind phase 2 to the same tunnel interface and I got this error message.

OperationCommit
ResultFailed

Details:
· Tunnel interface tunnel.1 multiple binding with different IKE gateways. IPSec tunnel: johng-fw-01. IKE gateway: johng-fw-01.

· Tunnel interface tunnel.1 multiple binding with different IKE gateways. IPSec tunnel: VPN-Z-Test-PA200. IKE gateway: VPN-Z-Test-PA200.

· Configuration is invalid

Can you please tell me how do you achive that?

Thanks,

Johnson

Palo Alto Networks Guru

Hi Johnson,

You cannot attach an IPSec tunnel to multiple IKE gateways. You can attach multiple IPSec tunnels to a common IKE gateway. This is commonly done to support >10 proxy IDs on a connection to a single VPN (IKE) peer. Can you please share a bit more information on what you're trying to do? That way we can recommend the correct configuration.

Thanks,

Nick

So for example, I could have 3 remote sites. Say site A, B and C. Then on the firewall I have 1 IKE Gateway configured. Site A, B and C could establish a VPN tunnel via the 1 IKE gateway I've configured on the firewall? In other words, each VPN tunnel configured on the firewall, would have the same IKE gateway set for it?

Palo Alto Networks Guru

Hi Alexander,

If you have three separate sites, you'll need a separate IKE gateway for each. The IKE gateway specifies the local and remote IP addresses that will be the termination points for each tunnel. In your case, you would configure three IKE gateways, and associate unique tunnel to each one.

Thanks,

Nick

Hi Nick,

I have worked with juniper SRX earlier, In order to configure site to multisite VPN's I use to configure "multipoint" option for the tunnel interface.

What is the additional option to used in PA , in order to configure Site-Multi Site VPN ?

Thanks

Retired Member
Not applicable

I believe that the feature that Juniper ScreenOS/SRX uses to support binding multiple VPNs to single tunnel interface is called next-hop tunnel binding (NHTB). This is not part of the RFC standard for IPsec and should be considered proprietary for Juniper. For the most part this allows to save on the number of tunnel interfaces that would need to be configured and is meant for hub-and-spoke configurations. The configuration though is not that simple in that despite sharing single tunnel interface as you still need to populate the NHTB table with either static NHTB entries or via routing protocol such as OSPF p2mp.

For PAN-OS there are two options to do similar scenario.

1. With 5.0 you can deploy large-scale VPN with Global Protect Satellite configuration. This is closest to Juniper NHTB. It is actually similar in that you can use a single tunnel interface and then can either specify routes to advertise to GP gateway or use OSPF to learn routes from all spoke sites. But also can do much more in that the configs on each satellite site is rather easy since you point each satellite site to the GP portal to automatically get all configs about each GP gateway to connect to.

2. Configure separate tunnel interface for each spoke site. There should not be an issue with limit on number of tunnel interfaces that can be configured (actually the limit is higher than the max number if SAs that can be configured). Then you can add each of the interfaces into OSPF p2p to learn each spoke site routes.

For reference, here is a good doc on the Large-Scale VPN feature in 5.0.

https://live.paloaltonetworks.com/docs/DOC-4139

Hope this helps.

-Richard

  • 1 accepted solution
  • 17951 Views
  • 8 replies
  • 0 Likes
Like what you see?

Show your appreciation!

Click Like if a post is helpful to you or if you just want to show your support.

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!