Score:0

Routing traffic from a bridge to a specific interface

br flag

Fundamental question about routing in Ubuntu 20.04.

I have a baremetal setup in Hetzner which has an 11.22.33.44/32 IPV4 address along with 2a01:db8:30/64 subnet allocated to it.

enp7s0 is the physical interface which has 11.22.33.44/32 address.

I also have the baremetal server connected to a vSwitch that has a Public subnet 2a01:1111:2222:3333::/64 allocated to it. The gateway for this subnet is 2a01:1111:2222:3333::1 and it is accessible via vlan.4001 interface (a sub interface of enp7s0 with VLAN tag id of 4001)

In my setup a bridge is created on the host called br1 with an ip address 2a01:1111:2222:3333::10/64. Multiple VMs are created on this bridge and each of the VMs have an IPV6 address allocated from the 2a01:1111:2222:3333::/64 IPV6 subnet. I have to use a bridge and there is no other option available due to various requirements.

The VMs that are on br1 can talk to each other and to the br1. I want to route all traffic to the external world from br1 via vlan.4001. I don't want to add vlan.4001 interface to the br1 (I don't want the VMs MAC addresses to be exposed to the vSWitch). I assigned the address 2a01:1111:2222:3333::2/64 to vlan.4001 but struggling to figure out how to route traffic from br1 to vlan.4001 interface.

As I mentioned earlier I do have to use a bridge to connect all the VMs on a host with the 2a01:1111:2222:3333::/64 (no NAT allowed for the VMs) and still be able to access external internet via vlan.4001.

Is this setup even possible using Ubuntu 20.04?

I also will not be able to use VRFs or netns, both of them are ruled out due to other requirements.

The only option I have is to use Policy Based routing but I am unable to create the PBR for the 2a01:1111:2222:3333::/64 to use the vlan.4001 interface for external traffic.

Tilman Schmidt avatar
bd flag
Not sure how a baremetal server (physical) would be connected to a vSwitch (virtual). Care to elaborate on that point? Also, what exactly are your reservations against exposing VM MAC addresses to the vSwitch?
ab_tech_sp avatar
br flag
@TilmanSchmidt, in a Hetzner bare metal setup, when you connect to vSwitch, which is done via their control panel, you receive traffic from the vSwitch on a tagged VLAN that is available on the main ethernet interface. Currently the Hetzner infrastructure does not allow more than 30 MAC addresses for a given server which limits the number of VMs that I can run on a single machine.
Score:1
bd flag

A bridge doesn't route. Bridging happens at layer 2, routing at layer 3. You'll have to make up your mind whether you want to route or to bridge between your internal network connecting the VMs (implemented by br1) and your Internet connection (vlan.4001). Either choice has specific consequences.

If you choose bridging, your VMs will talk directly to the gateway 2a01:1111:2222:3333::1, exposing their MAC address to that gateway and the intervening layer 2 network. On the other hand, that solution is very simple, and therefore more secure and reliable.

If you choose routing, you need a routing instance between your VMs and the external interface, and a separate network segment with its own IPv6 address range to connect that routing instance to the hoster's gateway router. So you'll have to ask Hetzner for another /64 they would route to your internal router, or alternatively for a /56 which you would then subnet yourself. The routing instance can be implemented as a dedicated VM running a firewall, or by the OS of your baremetal server.

Whether you use Ubuntu 20.04 or any other OS doesn't come into play at that level. Whatever solution you choose can be implemented with Ubuntu as well as with any other OS.

mangohost

Post an answer

Most people don’t grasp that asking a lot of questions unlocks learning and improves interpersonal bonding. In Alison’s studies, for example, though people could accurately recall how many questions had been asked in their conversations, they didn’t intuit the link between questions and liking. Across four studies, in which participants were engaged in conversations themselves or read transcripts of others’ conversations, people tended not to realize that question asking would influence—or had influenced—the level of amity between the conversationalists.