Enhanced Security Measures in Place:   To ensure a safer experience, we’ve implemented additional, temporary security measures for all users.

Multiple vpns to the same peer

cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 
Announcements

Multiple vpns to the same peer

L1 Bithead

Hi,

 

We have a requirement where-in we need to configure 2 vpn tunnels to the same remote peer.

Also the remote end local ip address ranges are the same. Below is a quick explanation

 

Tunnel 1

MyPeerPublicIp = 1.1.1.1

RemotePeerPublicIp = 2.2.2.2

MylocalSubnets = 10.1.1.0/24

RemoteLocalSunbets = 10.2.1.0/24

 

Tunnel 2

MyPeerPublicIp = 1.1.1.1

RemotePeerPublicIp = 2.2.2.2

MylocalSubnets = 10.1.2.0/24

RemoteLocalSunbets = 10.2.1.0/24

 

The two VPN devices at both ends are a PAN & Cisco ASA (peer destination).

 

My confusion is about the following question

 

1. Is it possible to have 2 vpns to the same peer ip? 

 

 

Any help on this issue will be much appreciated. Thank in advance.

 

Regards,

Adil

1 accepted solution

Accepted Solutions

Hi @adil.bgz,

 

If I understand your setup correctly you are trying to separate the encryption domain. But the only logical reason for doing this if you plan to use tunnel monitor

 

{Tunnel monitor feature will send ping packets to defined destination through the tunnel (encrypted) in order to detect if the IPsec tunnel is fully functional and if the ping fail it will mark the tunnel as down - even if phase1 and phase2 are still up. The source IP of this pings will be the ip assigned on your tunnel interface, so if you have multiple proxy-IDs defined for this tunnel, PAN FW will try to send the ping using all proxy-IDs, but if the local prefix for only one of the proxy-id is no matching your tunnel interface IP the whole tunnel will be marked as down}

 

If I understand your requirements you just want to limit the traffic through the tunnel so :

- Only X can talk to Y
- Only A can talk to B
- X cannot talk to B, and A cannot talk to Y

 

First of all you don't have to split the proxy-IDs into to different tunnel configurations. You just needs to configure only two proxy-IDs:
1. proxy-id-01: local prefix: X with remote prefix: Y
2. proxy-id-02: local prefix: A with remote prefix: B
That it is. However you can still use the suggestion by @OtakarKlier to use the security policy and configure rules allowing only X to Y and A to B. So the traffic will be dropped during the policy lookup.

But even if you don't do configure two rules and the firewall policy is actually allowing A to Y. The conenction between A to Y and X to B wouldn't be possible because you don't have configured proxy-ID for it. The actuall traffic will fail to match the encryption domain and traffic will be dropped from the tunnel.

 

 

On other hand if you still want to separate the encryption domains into two different tunnel configurations (using different proxy-ids) you need to assign same tunnel interface for both.

- Configure IPsec tunnel "A-to-B" with peer 1.1.1.1, assign tunnel.1, configure proxy-id local prefix: A with remote prefix: B

- Configure IPsec Tunnel "X-to-Y" with peer 1.1.1.1, assign tunnel.1, configure proxy id local prefix: X with remote prefix: Y

- configure static routes for B and Y with tunnel.1

- Configure policy to allow A to B and X to Y

 

View solution in original post

7 REPLIES 7

L7 Applicator

So, it sounds like you are wanting redundancy for the VPN tunnels? 

 

Also.. for clarification, you are wanting the following:

Tunnel1

PAN to remote Pan PublicIp = 1.1.1.1

 

Tunnel2

PAN to remote Cisco PublicIp = 1.1.1.1

 

You are wanting to setup 2 tunnels (both active?) with the same PublicIp = 1.1.1.1 and the same RemoteLocalSunbets = 10.2.1.0/24?

 

Just want to clarify as much as possible.

LIVEcommunity team member
Stay Secure,
Joe
Don't forget to Like items if a post is helpful to you!

Hi,

 

Thank you for answering me, my purpose is to separate 2 traffic from the same peers so that:

 

Tunnel 1

PAN to remote Cisco Public IP = 1.1.1.1

RemoteLocalSunbets : X

RemoteSubnets : Y

 

Tunnel 2

PAN to remote Cisco Public IP = 1.1.1.1

RemoteLocalSunbets : A

RemoteSubnets : B

 

When I try to implement the second tunnel, I have this message:

 

"IKE gateway Name_of_ike_gateway1 peer gateway address 1.1.1.1 is not unique among gateways using local address ethernet1/3. (Module: ikemgr)

IKE gateway Name_of_ike_gateway2 peer gateway address 1.1.1.1 is not unique among gateways using local address ethernet1/3. (Module: ikemgr)

configuration is invalide"

 

Thanks,

Hello,

Why not have just one VPN tunnel and use the PAN policies to determin what subnet traffic is allowed?

 

i.e. 

RemoteLocalSunbets : X RemoteSubnets : Y allowed

RemoteLocalSunbets : A RemoteSubnets : B allowed

then a DENY ALL policy at the bottom so the inter and intra zone policies are not used? 

 

This way Subnet X cannot talk to RemoteSubnet B and vice versa and same with Subnet A and subnetY.

 

Hope that makes sense.

Hi,

 

we have multiple virtual domain (VDOMs) / context / vsys, so we prefer to separate the traffic by tunnels inside the same link (PAN<=>ASA)

 

best regard,

Hi @adil.bgz,

 

If I understand your setup correctly you are trying to separate the encryption domain. But the only logical reason for doing this if you plan to use tunnel monitor

 

{Tunnel monitor feature will send ping packets to defined destination through the tunnel (encrypted) in order to detect if the IPsec tunnel is fully functional and if the ping fail it will mark the tunnel as down - even if phase1 and phase2 are still up. The source IP of this pings will be the ip assigned on your tunnel interface, so if you have multiple proxy-IDs defined for this tunnel, PAN FW will try to send the ping using all proxy-IDs, but if the local prefix for only one of the proxy-id is no matching your tunnel interface IP the whole tunnel will be marked as down}

 

If I understand your requirements you just want to limit the traffic through the tunnel so :

- Only X can talk to Y
- Only A can talk to B
- X cannot talk to B, and A cannot talk to Y

 

First of all you don't have to split the proxy-IDs into to different tunnel configurations. You just needs to configure only two proxy-IDs:
1. proxy-id-01: local prefix: X with remote prefix: Y
2. proxy-id-02: local prefix: A with remote prefix: B
That it is. However you can still use the suggestion by @OtakarKlier to use the security policy and configure rules allowing only X to Y and A to B. So the traffic will be dropped during the policy lookup.

But even if you don't do configure two rules and the firewall policy is actually allowing A to Y. The conenction between A to Y and X to B wouldn't be possible because you don't have configured proxy-ID for it. The actuall traffic will fail to match the encryption domain and traffic will be dropped from the tunnel.

 

 

On other hand if you still want to separate the encryption domains into two different tunnel configurations (using different proxy-ids) you need to assign same tunnel interface for both.

- Configure IPsec tunnel "A-to-B" with peer 1.1.1.1, assign tunnel.1, configure proxy-id local prefix: A with remote prefix: B

- Configure IPsec Tunnel "X-to-Y" with peer 1.1.1.1, assign tunnel.1, configure proxy id local prefix: X with remote prefix: Y

- configure static routes for B and Y with tunnel.1

- Configure policy to allow A to B and X to Y

 

Hi Alexander,

 

Thank you for answer, it's run as expected.

 

Best regard,

Very good explanation

It helped me a lot

MP

Help the community: Like helpful comments and mark solutions.
  • 1 accepted solution
  • 18894 Views
  • 7 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!