On 05/27/2014 02:46 AM, Brian Rak wrote:> Make sure you have: > > /proc/sys/net/bridge/bridge-nf-call-iptables = 1That doesn't make sense. bridge-nf-call-iptables controls whether or not traffic going across a Linux host bridge device will be sent through iptables, but the rules created by nwfilter are applied to the "vnetX" tap devices that connect the guest to the bridge, not to the bridge itself.> > On 5/26/2014 1:35 PM, Matt LaPlante wrote: >> I'm trying to accomplish what I had hoped would be a fairly simple >> filtering of traffic to my VMs, but I'm hitting a snag. The VMs are >> allowing traffic when I wouldn't expect them to. >> >> Host and Guest are both running the same platform: >> Ubuntu 12.04.4 LTS >> 0.9.8-2ubuntu17.19 >> >> I have a basic bridge enabled on the host: >> brctl addbr brdg >> brctl addif brdg eth1 >> ip link set brdg up >> >> The host has iptables support: >> root@host:~# lsmod | grep filt >> ip6table_filter 12815 0 >> ip6_tables 27864 2 ip6table_filter,xt_TPROXY >> iptable_filter 12810 1 >> ip_tables 27473 4 >> iptable_raw,iptable_nat,iptable_mangle,iptable_filter >> x_tables 29891 52 >> ebt_arp,ebt_ip,ip6table_filter,ebtables,xt_time,xt_connlimit,xt_realm,xt_addrtype,iptable_raw,xt_comment,xt_recent,xt_policy,ipt_ULOG,ipt_REJECT,ipt_REDIRECT,ipt_NETMAP,ipt_MASQUERADE,ipt_ECN,ipt_ecn,ipt_CLUSTERIP,ipt_ah,xt_set,xt_TPROXY,ip6_tables,xt_tcpmss,xt_pkttype,xt_physdev,xt_owner,xt_NFQUEUE,xt_NFLOG,xt_multiport,xt_mark,xt_mac,xt_limit,xt_length,xt_iprange,xt_helper,xt_hashlimit,xt_DSCP,xt_dscp,xt_dccp,xt_conntrack,xt_connmark,xt_CLASSIFY,xt_AUDIT,ipt_LOG,xt_tcpudp,xt_state,iptable_nat,iptable_mangle,iptable_filter,ip_tables >> >> >> Guest network using bridge: >> <interface type='bridge'> >> <mac address='00:11:22:33:44:55'/> >> <source bridge='brdg'/> >> <model type='virtio'/> >> <filterref filter='outbound-only'/> >> <address type='pci' domain='0x0000' bus='0x00' slot='0x03' >> function='0x0'/> >> </interface> >> >> <filter name='outbound-only' chain='root'> >> <uuid>0c834381-402c-faf3-019f-eb5a40ea6b61</uuid> >> <filterref filter='allow-arp'/> >> <filterref filter='allow-dhcp'/> >> <filterref filter='qemu-announce-self'/> >> <filterref filter='no-other-l2-traffic'/> >> </filter>Comparing the examples on this page: http://libvirt.org/formatnwfilter.html to the contents of the no-other-l2-traffic filter, I see that the manually constructed examples of "block all other traffic" on that page include an <all/> element in the filter. Possibly that was accidentally left out of the no-other-l2-traffic filter, so it isn't actually blocking anything? (that's just a guess, as I don't personally use nwfilter and don't have time to try it out right now)>> >> My goal is to allow the guest to reach the internet, but not allow the >> internet or other guests to reach this guest. I realize this config >> is not sufficient for that, but I can't get any farther until I >> understand the current behavior. From the look of the config, this >> should essentially not be allowing anything except arp and dhcp. And >> yet, the host has full connectivity. I can run apt-get update on the >> VM, I can ping the VM from other nodes in my network, etc. It's >> basically wide-open. So either one of the included rules is not >> working as advertised, or I'm misunderstanding some feature of the >> filtering process.
On 5/28/2014 10:10 AM, Laine Stump wrote:> On 05/27/2014 02:46 AM, Brian Rak wrote: >> Make sure you have: >> >> /proc/sys/net/bridge/bridge-nf-call-iptables = 1 > That doesn't make sense. bridge-nf-call-iptables controls whether or not > traffic going across a Linux host bridge device will be sent through > iptables, but the rules created by nwfilter are applied to the "vnetX" > tap devices that connect the guest to the bridge, not to the bridge itself.It may not make sense to you, but that is what's necessary for nwfilter to work. You can even look at the code: http://libvirt.org/git/?p=libvirt.git;a=blob;f=src/nwfilter/nwfilter_ebiptables_driver.c;h=5cb0b74aaec2a659fb6e4b61502ef1322131c056;hb=HEAD#l3127>> On 5/26/2014 1:35 PM, Matt LaPlante wrote: >>> I'm trying to accomplish what I had hoped would be a fairly simple >>> filtering of traffic to my VMs, but I'm hitting a snag. The VMs are >>> allowing traffic when I wouldn't expect them to. >>> >>> Host and Guest are both running the same platform: >>> Ubuntu 12.04.4 LTS >>> 0.9.8-2ubuntu17.19 >>> >>> I have a basic bridge enabled on the host: >>> brctl addbr brdg >>> brctl addif brdg eth1 >>> ip link set brdg up >>> >>> The host has iptables support: >>> root@host:~# lsmod | grep filt >>> ip6table_filter 12815 0 >>> ip6_tables 27864 2 ip6table_filter,xt_TPROXY >>> iptable_filter 12810 1 >>> ip_tables 27473 4 >>> iptable_raw,iptable_nat,iptable_mangle,iptable_filter >>> x_tables 29891 52 >>> ebt_arp,ebt_ip,ip6table_filter,ebtables,xt_time,xt_connlimit,xt_realm,xt_addrtype,iptable_raw,xt_comment,xt_recent,xt_policy,ipt_ULOG,ipt_REJECT,ipt_REDIRECT,ipt_NETMAP,ipt_MASQUERADE,ipt_ECN,ipt_ecn,ipt_CLUSTERIP,ipt_ah,xt_set,xt_TPROXY,ip6_tables,xt_tcpmss,xt_pkttype,xt_physdev,xt_owner,xt_NFQUEUE,xt_NFLOG,xt_multiport,xt_mark,xt_mac,xt_limit,xt_length,xt_iprange,xt_helper,xt_hashlimit,xt_DSCP,xt_dscp,xt_dccp,xt_conntrack,xt_connmark,xt_CLASSIFY,xt_AUDIT,ipt_LOG,xt_tcpudp,xt_state,iptable_nat,iptable_mangle,iptable_filter,ip_tables >>> >>> >>> Guest network using bridge: >>> <interface type='bridge'> >>> <mac address='00:11:22:33:44:55'/> >>> <source bridge='brdg'/> >>> <model type='virtio'/> >>> <filterref filter='outbound-only'/> >>> <address type='pci' domain='0x0000' bus='0x00' slot='0x03' >>> function='0x0'/> >>> </interface> >>> >>> <filter name='outbound-only' chain='root'> >>> <uuid>0c834381-402c-faf3-019f-eb5a40ea6b61</uuid> >>> <filterref filter='allow-arp'/> >>> <filterref filter='allow-dhcp'/> >>> <filterref filter='qemu-announce-self'/> >>> <filterref filter='no-other-l2-traffic'/> >>> </filter> > Comparing the examples on this page: > > http://libvirt.org/formatnwfilter.html > > to the contents of the no-other-l2-traffic filter, I see that the > manually constructed examples of "block all other traffic" on that page > include an <all/> element in the filter. Possibly that was accidentally > left out of the no-other-l2-traffic filter, so it isn't actually > blocking anything? (that's just a guess, as I don't personally use > nwfilter and don't have time to try it out right now) > >>> My goal is to allow the guest to reach the internet, but not allow the >>> internet or other guests to reach this guest. I realize this config >>> is not sufficient for that, but I can't get any farther until I >>> understand the current behavior. From the look of the config, this >>> should essentially not be allowing anything except arp and dhcp. And >>> yet, the host has full connectivity. I can run apt-get update on the >>> VM, I can ping the VM from other nodes in my network, etc. It's >>> basically wide-open. So either one of the included rules is not >>> working as advertised, or I'm misunderstanding some feature of the >>> filtering process.
On Wed, May 28, 2014 at 10:13:14AM -0400, Brian Rak wrote:> > On 5/28/2014 10:10 AM, Laine Stump wrote: > >On 05/27/2014 02:46 AM, Brian Rak wrote: > >>Make sure you have: > >> > >>/proc/sys/net/bridge/bridge-nf-call-iptables = 1 > >That doesn't make sense. bridge-nf-call-iptables controls whether or not > >traffic going across a Linux host bridge device will be sent through > >iptables, but the rules created by nwfilter are applied to the "vnetX" > >tap devices that connect the guest to the bridge, not to the bridge itself. > It may not make sense to you, but that is what's necessary for nwfilter to > work. You can even look at the code: > > http://libvirt.org/git/?p=libvirt.git;a=blob;f=src/nwfilter/nwfilter_ebiptables_driver.c;h=5cb0b74aaec2a659fb6e4b61502ef1322131c056;hb=HEAD#l3127You are both right and both wrong :-P The nwfilter code does need nf-call-iptables==1, but if-and-only-if the nwfilter rule specified in the XML is filtering at the IPv4/IPv6 layer protocol. Any rules which are ethernet layer don't care about these sysctl settings. See this: http://libvirt.org/formatnwfilter.html#nwfelemsRulesProto mac, vlan, stp, arp, rarp, ipv4 and ipv6 protocols are all done at the ethernet layer. tcp, udp, sctp, icmp, igmp, esp, ah, udplite (and their IPv6 variants) are all done at the IP layer. Regards, Daniel -- |: http://berrange.com -o- http://www.flickr.com/photos/dberrange/ :| |: http://libvirt.org -o- http://virt-manager.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: http://entangle-photo.org -o- http://live.gnome.org/gtk-vnc :|
On 05/28/2014 05:13 PM, Brian Rak wrote:> > On 5/28/2014 10:10 AM, Laine Stump wrote: >> On 05/27/2014 02:46 AM, Brian Rak wrote: >>> Make sure you have: >>> >>> /proc/sys/net/bridge/bridge-nf-call-iptables = 1 >> That doesn't make sense. bridge-nf-call-iptables controls whether or not >> traffic going across a Linux host bridge device will be sent through >> iptables, but the rules created by nwfilter are applied to the "vnetX" >> tap devices that connect the guest to the bridge, not to the bridge >> itself. > It may not make sense to you, but that is what's necessary for > nwfilter to work. You can even look at the code: > > http://libvirt.org/git/?p=libvirt.git;a=blob;f=src/nwfilter/nwfilter_ebiptables_driver.c;h=5cb0b74aaec2a659fb6e4b61502ef1322131c056;hb=HEAD#l3127 >Once again showing how much attention I pay to details :-) It still doesn't make sense, but you are correct. (and to think that virt people have spent so much time complaining that the bridge-nf-* settings should be *off*...)