CentOS 7 host, pfSense guest: Problems connecting host as LAN client via MACVLAN

So I almost have this working, but it’s highly hacky and doesn’t work properly. I’d like to ask, what’s the proper way of doing this, and how to fix one particular problem? My situation is thus:

CentOS 7 host with a pfSense KVM guest, to which the physical WAN ethernet port is MACVTAP passthrough-ed and the physical LAN port is MACVTAP bridged, both successfully. Using virtio drivers and using virt-manager. Other KVM clients succesfully connect on the LAN MACVTAP bridged port, as do other physical machines. But my issues are about trying to connect the host machine as a LAN client.

Actually, it sort-of works. What I’ve done on the host is make a MACVLAN bridge link, and then run dhclient to connect:

ip link add link eno2 name macvlan0 address BLABLA type macvlan mode bridge
ip link set dev macvlan0 up
dhclient macvlan0

BLABLA is a made-up mac address. This connects as a LAN client and it gets an IP address and it connects to the internet. But, it occasionally disconnects – maybe the lease runs out and it doesn’t ask for another? And also, it doesn’t take a hostname/domainname by which other LAN clients can connect to it. Instead, I have to connect to it by its IP address.

So what’s the right way to set this up, and how can I get it to receive a hostname like all my other clients?

Kind regards.

@igenix, I have a CentOS7 host with pfSense in KVM as well. However, due to the nature of my setup I created a “nat” network and an “isolated” network within KVM. Stuck a nic in each network attached to the pfsense vm. Then each vm I wanted to be “behind” pfsense went into the “isolated” network.

In order to make this work I tried to setup nat rules with firewalld, but then I found that the rules KVM puts in place for the nat and isolated networks trap the traffic before it gets to the rules I put in.

What I wound up having to do was create a hook within qemu to run on different vm actions.

See here for information on hooks from libvirt:

https://www.libvirt.org/hooks.html

And here is a rough example of what I implemented based off of a stack overflow post that I would credit if I could find it again at the moment. In /etc/libvirt/hooks/qemu (had to create this script and make it executable as it did not exist):

https://pastebin.com/VZLa7WjT

Keep in mind I added to the script I found on SO and some of the stuff I did is rather “quick and dirty” it can probably be improved. It offers a 1 to 1 nat on the port number because I was rather lazy.

I can poke around tomorrow to see if I can offer assistance with bridged networking.

1 Like

Macvtap generally does not allow for guest to host communication. What you want to do instead is create a bridge interface from the physical nic on the host machine and assign the hosts ip to the bridge rather than the physical nic. Then also use the bridge for the VM.

I can be more specific if you’d like.

2 Likes

Though the OP should know that if they use bridge networking and are intending the pfsense vm to act as the gateway for their entire network and this is a home lab, often times when placing your cable modem in bridge mode you end up with only one ip and if the host gets the ip then the guest will not and vice versa. I don’t know the entire topology of OP’s environment but it seems worthwhile to point out.

You don’t need to assign the host interface an address so this isn’t a problem. OP is talking about the LAN interface which needs to work for the host aswell as the VM.

1 Like

I know you don’t need to/want to assign the host an address on the bridge. I wanted to highlight that in case igenix sets it to DHCP and then was chasing connection issues.

Cheers guys, looks like an alternative to macvlan bridging is worth investigating. I liked the elegance of treating the host like the other guests, but this weekend I’ll try following the ideas of @uberentwickelt and @Dexter_Kane . Yeah, it’s a homelab and the modem connection seems to work fien just passed to pfsense.

I’ll be in touch!

1 Like