Re: [libvirt-users] Network filters with clean-traffic not working on Debian Stretch
Hi Sam, You can find the rules by below command, and it looks as below: # ebtables -t nat --list Bridge table: nat Bridge chain: PREROUTING, entries: 2, policy: ACCEPT -j PREROUTING_direct -i vnet0 -j libvirt-I-vnet0 Bridge chain: OUTPUT, entries: 1, policy: ACCEPT -j OUTPUT_direct Bridge chain: POSTROUTING, entries: 2, policy: ACCEPT -j POSTROUTING_direct -o vnet0 -j libvirt-O-vnet0 Bridge chain: PREROUTING_direct, entries: 0, policy: RETURN Bridge chain: POSTROUTING_direct, entries: 0, policy: RETURN Bridge chain: OUTPUT_direct, entries: 0, policy: RETURN Bridge chain: libvirt-I-vnet0, entries: 9, policy: ACCEPT -j I-vnet0-mac -p IPv4 -j I-vnet0-ipv4-ip -p IPv4 -j ACCEPT -p ARP -j I-vnet0-arp-mac -p ARP -j I-vnet0-arp-ip -p ARP -j ACCEPT -p 0x8035 -j I-vnet0-rarp -p 0x835 -j ACCEPT -j DROP Bridge chain: libvirt-O-vnet0, entries: 4, policy: ACCEPT -p IPv4 -j O-vnet0-ipv4 -p ARP -j ACCEPT -p 0x8035 -j O-vnet0-rarp -j DROP Bridge chain: I-vnet0-mac, entries: 2, policy: ACCEPT -s 52:54:0:3a:40:b7 -j RETURN -j DROP Bridge chain: I-vnet0-ipv4-ip, entries: 3, policy: ACCEPT -p IPv4 --ip-src 0.0.0.0 --ip-proto udp -j RETURN -p IPv4 --ip-src 172.16.1.2 -j RETURN -j DROP Bridge chain: O-vnet0-ipv4, entries: 1, policy: ACCEPT -j ACCEPT Bridge chain: I-vnet0-arp-mac, entries: 2, policy: ACCEPT -p ARP --arp-mac-src 52:54:0:3a:40:b7 -j RETURN -j DROP Bridge chain: I-vnet0-arp-ip, entries: 2, policy: ACCEPT -p ARP --arp-ip-src 172.16.1.2 -j RETURN -j DROP Bridge chain: I-vnet0-rarp, entries: 2, policy: ACCEPT -p 0x8035 -s 52:54:0:3a:40:b7 -d Broadcast --arp-op Request_Reverse --arp-ip-src 0.0.0.0 --arp-ip-dst 0.0.0.0 --arp-mac-src 52:54:0:3a:40:b7 --arp-mac-dst 52:54:0:3a:40:b7 -j ACCEPT -j DROP Bridge chain: O-vnet0-rarp, entries: 2, policy: ACCEPT -p 0x8035 -d Broadcast --arp-op Request_Reverse --arp-ip-src 0.0.0.0 --arp-ip-dst 0.0.0.0 --arp-mac-src 52:54:0:3a:40:b7 --arp-mac-dst 52:54:0:3a:40:b7 -j ACCEPT -j DROP For interface set as: --- Best Regards, Yalan Zhang IRC: yalzhang On Wed, Dec 26, 2018 at 12:28 AM fatal wrote: > Hello, > > I'm recently stumbled over the libvirt network filter capabilities and > got pretty excited. Unfortunately I'm not able to get the the > "clean-traffic" filterset working. I'm using a freshly installed Debian > Stretch with libvirt, qemu and KVM. > > My config snippet looks as follows: > > sudo virsh edit > > [...] > > > > > > > >function='0x0'/> > > > > > > > > >function='0x0'/> > > [...] > > I restarted the VM from within the VM, did a "virsh reboot ", > restarted libvirtd and even did a reboot of the host - just to be sure. > Unfortunately neither "iptables -L" nor "ebtables --list" show any > entries added by libvirt. Also omitting the "parameter name='IP'" part > didn't change anything. > > There are no error messages in /var/log/syslog nor in > /var/log/libvirt/qemu/ > > My main references were: > > https://libvirt.org/firewall.html > https://libvirt.org/formatnwfilter.html > > https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/7/html/virtualization_deployment_and_administration_guide/sect-virtual_networking-applying_network_filtering > > https://www.berrange.com/posts/2011/10/03/guest-mac-spoofing-denial-of-service-and-preventing-it-with-libvirt-and-kvm/ > > Any help really would be much appreciated! > > Thanks a lot! > > Sam > > ___ > libvirt-users mailing list > libvirt-users@redhat.com > https://www.redhat.com/mailman/listinfo/libvirt-users > ___ libvirt-users mailing list libvirt-users@redhat.com https://www.redhat.com/mailman/listinfo/libvirt-users
Re: [libvirt-users] macvtap and tagged VLANs to the VM
Hi, nobody? If this is the wrong forum, where can I find people who can help with this issue? Greetings Marc On Sun, Dec 16, 2018 at 10:59:22PM +0100, Marc Haber wrote: > From: Marc Haber > Subject: macvtap and tagged VLANs to the VM > To: libvirt-users@redhat.com > Date: Sun, 16 Dec 2018 22:59:22 +0100 > User-Agent: Mutt/1.9.5 (2018-04-13) > > Hi, > > I would like to run a network firewall as a VM on a KVM host. There are > ~ 25 VLANs delivered to the KVM host on three dedicated links, no LACP > or other things. I have the VLANs 100-180 on the host's enp1s0, the VLANs > 200-280 on the host's enp2s0 and the VLANs 300-380 on the host's enp3s0. > > To save myself from configuring all VLANs on the KVM host, I'd like to > hand the entire ethernet link to the VM and to have the VLAN interfaces > there. Using classical Linux bridges (brctl), things work fine. > > They don't when I try macvlan: > > On the host: > 4: enp3s0: mtu 1500 qdisc pfifo_fast state > UP mode DEFAULT group default qlen 1000 > link/ether 00:0d:b9:34:2a:fe brd ff:ff:ff:ff:ff:ff promiscuity 1 > addrgenmode eui64 numtxqueues 1 numrxqueues 1 gso_max_size 65536 gso_max_segs > 65535 > 5: unt382@enp3s0: mtu 1500 qdisc noqueue > state UP mode DEFAULT group default qlen 1000 > link/ether 00:0d:b9:34:2a:fe brd ff:ff:ff:ff:ff:ff promiscuity 0 > vlan protocol 802.1Q id 382 addrgenmode eui64 numtxqueues 1 > numrxqueues 1 gso_max_size 65536 gso_max_segs 65535 > 15: macvtap3@enp3s0: mtu 1500 > qdisc pfifo_fast state UP mode DEFAULT group default qlen 500 > link/ether 52:54:00:bf:bb:ab brd ff:ff:ff:ff:ff:ff promiscuity 0 > macvtap mode bridge addrgenmode eui64 numtxqueues 1 numrxqueues 1 > gso_max_size 65536 gso_max_segs 65535 > > 4: enp3s0: mtu 1500 qdisc pfifo_fast state > UP group default qlen 1000 > link/ether 00:0d:b9:34:2a:fe brd ff:ff:ff:ff:ff:ff > inet6 fe80::20d:b9ff:fe34:2afe/64 scope link >valid_lft forever preferred_lft forever > 5: unt382@enp3s0: mtu 1500 qdisc noqueue > state UP group default qlen 1000 > link/ether 00:0d:b9:34:2a:fe brd ff:ff:ff:ff:ff:ff > inet6 fe80::20d:b9ff:fe34:2afe/64 scope link >valid_lft forever preferred_lft forever > 15: macvtap3@enp3s0: mtu 1500 > qdisc pfifo_fast state UP group default qlen 500 > link/ether 52:54:00:bf:bb:ab brd ff:ff:ff:ff:ff:ff > inet6 fe80::5054:ff:febf:bbab/64 scope link >valid_lft forever preferred_lft forever > > > In the XML: > > > > > > >function='0x0'/> > > > And in the VM: > root@grml ~ # ip -d link show > 1: lo: mtu 65536 qdisc noqueue state UNKNOWN mode > DEFAULT group default qlen 1 > link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00 promiscuity 0 > addrgenmode eui64 numtxqueues 1 numrxqueues 1 gso_max_size 65536 gso_max_segs > 65535 > 2: eth0: mtu 1500 qdisc pfifo_fast state UP > mode DEFAULT group default qlen 1000 > link/ether 52:54:00:bf:bb:ab brd ff:ff:ff:ff:ff:ff promiscuity 0 > addrgenmode eui64 numtxqueues 1 numrxqueues 1 gso_max_size 65536 gso_max_segs > 65535 > 3: vlan0@eth0: mtu 1500 qdisc noqueue state > UP mode DEFAULT group default qlen 1000 > link/ether 52:54:00:bf:bb:ab brd ff:ff:ff:ff:ff:ff promiscuity 0 > vlan protocol 802.1Q id 382 addrgenmode eui64 numtxqueues 1 > numrxqueues 1 gso_max_size 65536 gso_max_segs 65535 > root@grml ~ # ip a > 1: lo: mtu 65536 qdisc noqueue state UNKNOWN group > default qlen 1 > link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00 > inet 127.0.0.1/8 scope host lo >valid_lft forever preferred_lft forever > inet6 ::1/128 scope host >valid_lft forever preferred_lft forever > 2: eth0: mtu 1500 qdisc pfifo_fast state UP > group default qlen 1000 > link/ether 52:54:00:bf:bb:ab brd ff:ff:ff:ff:ff:ff > inet6 fe80::5054:ff:febf:bbab/64 scope link >valid_lft forever preferred_lft forever > 3: vlan0@eth0: mtu 1500 qdisc noqueue state > UP group default qlen 1000 > link/ether 52:54:00:bf:bb:ab brd ff:ff:ff:ff:ff:ff > inet 192.168.252.220/24 brd 192.168.252.255 scope global vlan0 >valid_lft forever preferred_lft forever > inet6 fe80::5054:ff:febf:bbab/64 scope link >valid_lft forever preferred_lft forever > root@grml ~ # > > I then ping from the VM to 192.168.252.241, which is a differnt host on > the network, neither the VM host the VM is running on nor another VM on > the same host. That should rule out the connectivity issues that a > macvtap interface has, right? On the VM, I see ARP requests going out, > but no answers come in. > > On the pinged host, I see: > 22:50:23.881163 52:54:00:bf:bb:ab > ff:ff:ff:ff:ff:ff, ethertype ARP > (0x0806), length 60: Request who-has 192.168.252.241 tell 192.168.252.220, > length 46 > 22:50:23.881242 52:54:00:95:df:a6 > 52:54:00:bf:bb:ab, ethertype ARP > (0x0806), length 42: Reply 192.168.252.241 is-at 52:54:00:95:df:a6, length 28 > >
