0

Determined to turn an old computer into a server (NAS, Home assistant, ...), I decided to learn about Virtualization with Xen Project on Debian. The server is expected to be used on LAN only and it has the static IP address 10.56.0.191. I am trying to create a guest on 10.56.0.192 with Xen. To this end, I followed the informations given in the Xen project's beginners guide and I have been able to create a VP guest running Debian as well.

Unfortunately, the guest has no connection at all. Still following the beginners guide, together with Xen networking, I tried to configure the host's interface, IP forwarding, ARP proxy, and IP masquerading. Unfortunately, the wiki refers to iptable which appears to had been superseeded with nftables. Therefore, I am trying to use nftables.

The guest seems to be unable to communicate (connection tested by pinging various hosts on LAN), while the host can communicate properly.

It seems I am missing something important but I am unable to find it out. Would you please help me with this issue?

I configured the host and the guest as follows.

I thank you for your help :-)

On the host

I created a bridge, xenbr0, into /etc/network/interfaces as follows:

source /etc/network/interfaces.d/* # The loopback network interface auto lo iface lo inet loopback # Static IP on ethernet iface enp2s0 inet manual # Bridge for Xen hypervisor auto xenbr0 iface xenbr0 inet static address 10.56.0.191 netmask 255.255.0.0 gateway 10.56.0.1 dns-nameservers 1.1.1.1 4.4.4.4 8.8.8.8 bridge_ports enp2s0 bridge_stp off bridge_maxwait 0 bridge_fd 0

The IPv4 forwarding and the ARP proxy both are enabled into /etc/sysctl.conf.

net.ipv4.ip_forward=1 net.ipv4.conf.enp2s0.proxy_arp=1

With nftables, I created a nat table and a postrouting chain. Then I added a rule for the IP masquerading.

nft add table nat nft add chain ip nat postrouting { type nat hook postrouting priority 0 \; } nft add rule nat postrouting ip saddr 10.56.0.0/16 oif enp2s0 masquerade

Calling nft list ruleset returns the following:

table ip nat { chain postrouting { type nat hook postrouting priority filter; policy accept; ip saddr 10.56.0.0/16 oif "enp2s0" masquerade } }

On the guest

Within the guest configuration file, the virtual interface is set as vif = [ 'ip=10.56.0.192 ,mac=00:16:3E:FA:9C:76, bridge=xenbr0' ]

I also trying to configure its network interface by setting a static IP into /etc/network/interfaces:

auto lo iface lo inet loopback auto enX0 iface enX0 inet static address 10.56.0.192 gateway 10.56.0.1 netmask 255.255.0.0 dns-nameservers 1.1.1.1 4.4.4.4 8.8.8.8
Improve this question
17
  • I don't understand the setup here. The bridge with enp2s0 makes sense on its own, and the NAT rule makes sense on its own, but the combined result is nonsensical – either the traffic is bridged to your LAN or it's routed (with or without NAT), not both, they're contradictory configurations... Commented Dec 29, 2024 at 22:33
  • Thank you for your comment @grawity. I am not expert enough to perfectly understand all that networking stuffs. My understanding is we create a bridge between the physical interface and a virtual interface (VIF). Then, we need to route the packages from the VIF to the LAN. (See the picture on Xen's wiki networking page). Does is make sense? Commented Dec 30, 2024 at 8:10
  • That diagram makes sense (bridge being optional), but if you want traffic to be routed, then your physical eth0 should not be part of the bridge! Because if it's part of the bridge, and if the VM is told to talk to 10.56.0.1 (which I assume is your physical LAN gateway)... it will indeed do just that, bypassing the host's routing and going straight through the bridge. (And vice versa, the VM's 10.56.0.192 address will of course be part of your LAN.) Commented Dec 30, 2024 at 8:25
  • Something similar applies to your use of proxy-ARP. What's the goal of proxy-ARP, and what's the goal of masquerade (rather than bridging)? I would have assumed that the reason of using masquerade was that you weren't allowed to bring other IPs and/or MACs into the LAN, but doesn't that contradict the use of proxy-ARP? Is it specifically that the MAC address has to remain that of the host but additional IPs are allowed, or what? Commented Dec 30, 2024 at 8:28
  • Thanks again. All those concepts are far from my field of expertise and I certainly need to read more about all of them to better understand what I am doing here. If I understand correctly, you are saying this should work with the bridge alone. Is this correct? (I tried already, and it did not work) Commented Dec 31, 2024 at 10:07

1 Answer 1

Reset to default
0

If the VIF representing the VM guest is supposed to be in the bridge, then NAT on the VM host is irrelevant as it communicates directly via the bridge and doesn't even use the host as a gateway.

But from comments, it seems that Xen doesn't put the VIF in the bridge as it should. Do that manually using ip link set <vif_name> master xenbr0.

My guess is that Xen ignores your entire vif = configuration because of the ip= parameter which shouldn't be there – I couldn't find it in documentation, and indeed it doesn't even make sense for ip= to exist because the hypervisor only has control over the guest's MAC address (which is emulated hardware) but not over the guest's IP address (which is something that the guest decides in software).

Initial answer written last week:

The setup you have is a mix of several contradictory configurations. In particular you have a mix of "bridged" and "routed" setup:

  • If enp2s0 is part of the bridge, then effectively the VM is directly connected to the same LAN as the host is (at Ethernet level) – it'll directly talk to the physical LAN gateway at 10.56.0.1, and so on.

    But if the VM is configured to use 10.56.0.1 as its gateway (taking the shortcut through the bridge)... that means it won't use 10.56.0.191 (the host PC) as its gateway, and therefore its traffic won't go through the host's IP processing, including any nftables NAT rules.

    Not that NAT would be needed, anyway – both NAT and proxy-ARP would also be completely unnecessary in this setup. Proxy-ARP is redundant because the bridge already forwards the real ARP requests/responses straight to the VM, so there's no need for the host to answer on its behalf; NAT is redundant because both addresess are within the same subnet, so the gateway already knows a route to the VM's real address anyway (again, straight through the bridge).

    So if you want a bridged setup where the VM is a full member of the physical LAN, the first thing to do would be to disable proxy-ARP again and make sure that the physical router correctly learns the VM's real MAC address (usually ARP cache entries expire after a short while). The second thing – if you're doing this on some corporate LAN – would be to contact whoever manages the network.

  • On the other hand, if a routed setup with NAT is desired (in order to hide the VM's existence from the physical LAN), then enp2s0 shouldn't be part of the bridge at all. Instead, enp2s0 and xenbr0 should be two separate interfaces with separate IP configurations – and more importantly, with non-overlapping IP subnets.

    For example, since the LAN uses 10.56.0.0/16, you might use 192.168.44.0/24 for your Xen network, and the VM would be configured to use the host (e.g. 192.168.44.1) as its gateway.

    Since routing is implicit, it also has to be enabled system-wide via /etc/sysctl.conf on the host system (net.ipv4.conf.all.forwarding=1).

    (Technically speaking, if the bridge only ever contains just this single VM, then the bridge overall is redundant; routing can be done directly between enp2s0 and the individual interface representing the VM. Still, using a bridge makes several other things more convenient.)

Improve this answer

You must log in to answer this question.

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.