Tunnel Terminations: Add multiple VPN tunnels to one physical interface

[akienz]

Hello together,

I am currently trying out the new VPN Tunnel management feature. We currently have a router/firewall with multiple IPsec VPN tunnels on the www uplink interface (with the same public ipv4). While trying to document these with the new Tunnel feature introduced in Netbox 3.7.0 i noticed that only one Tunnel Termination can be added per (physical oder virtual) interface:

How would be the recommed way to document multiple vpn tunnels terminating on the same interface? I thought about creating a virtual subinterface peer termination, e.g. ether1.tunnel1 per termination, but not sure if this is the right way.

Would there be a technical reason (except the current data model maybe) to not allow multiple terminations per interface?

Best regards!

[jeremystretch]

Each tunnel termination should be modeled by a separate virtual interface on the device or virtual machine. This is how route-based tunnels are configured, so this is how they are modeled in NetBox.

[dirtycache]

That applies for route based tunnels and their "inside" IP addresses, but in the case of termination, or "outside" endpoint addresses, it is very well possible to have multiple, different tunnels terminating to the same address bound to an interface. Like so:

[DeviceA]--[Interface:WAN}--[IP Addr 192.0.2.1] <----Tunnel 1 ----> [IP Addr 198.51.100.10]--[Interface:WAN]--[Device B]

and

[DeviceA]--[Interface:WAN}--[IP Addr 192.0.2.1] <----Tunnel 2 ----> [IP Addr 203.0.113.10]--[Interface:WAN]--[Device C]

Within Tunnel 1 between peers 192.0.2.1 and 198.51.100.10 you may have inside addresses on logical interfaces named something like vti0, like a /30 -- and a different inside /30 on Tunnel 2. Ergo, the fact that the termination is specifically asking for outside IP addresses/interfaces would seem to imply that the correct interface for the termination is in fact the underlay interface rather than the tunnel interface.

Caveat: unless I'm missing some piece of understanding here.

Thanks!

[jeremystretch]

That applies for route based tunnels and their "inside" IP addresses, but in the case of termination, or "outside" endpoint addresses, it is very well possible to have multiple, different tunnels terminating to the same address bound to an interface.

What you're describing are policy-based tunnels, which NetBox does not support as it was not in scope for #9816. Even if NetBox permitted multiple tunnels to terminate on the same interface, there would be no mechanism for differentiating among them. (This would require modeling what Cisco refers to as crypto maps.)

[DanSheps]

This is correct, for the Tunnel interface, but not for the outside IP.

The Outside IP can be bound to multiple Tunnel interfaces. I will admit, I haven't had a chance to look at the model/logic or test it out myself but we should allow multiple outside IP's to be bound to different tunnel terminations.

[markkuleinio]

#14706 opened for this

[markkuleinio]

I only now tested with two VPN tunnels, and I don't right away get it how the NetBox VPN data model should be used.

When I'm adding the second VPN tunnel and create the our-side VPN tunnel termination, I'm trying to select the correct outside IP, that is the public Internet-facing IP of the VPN device, but NetBox says:

Tunnel termination with this Outside ip already exists.

That's true, all VPN tunnels are using the same outside IP. But that doesn't seem to be allowed.

How should this be used instead?

I get it that I can use it like this:

• Since the same outside IP cannot be selected for all tunnels, I can just leave the outside IP unselected for my side (and just "know" what the public IP is, or I can use a tag or custom field for that for now)
• There is no IP address in the tunnel interface (true, no need to have IP on there)
• For the other-side peer I don't need to know the tunnel interface so I'd rather leave it unselected, but since it is mandatory, I'm adding the device with only the public interface as "Internet" and assign their outside IP there as that is the crucial piece of information in my side

[dirtycache]

Ah, I see now. I was inferring the interface object should be that to which the outside IP address was bound rather than the tunnel interface. Thank you! On Jan 5, 2024, at 11:04 AM, Daniel Sheppard ***@***.***> wrote:  This is correct, for the Tunnel interface, but not for the outside IP. The Outside IP can be bound to multiple Tunnel interfaces. I will admit, I haven't had a chance to look at the model/logic or test it out myself but we should allow multiple outside IP's to be bound to different tunnel terminations. — Reply to this email directly, view it on GitHub<#14666 (reply in thread)>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/AEHM5Y43EFZ5ZKTW2U24HITYNAXBFAVCNFSM6AAAAABBLLCNF2VHI2DSMVQWIX3LMV43SRDJONRXK43TNFXW4Q3PNVWWK3TUHM4DAMRVGIYDA>. You are receiving this because you are subscribed to this thread.Message ID: ***@***.***>