veth support

[jnorell]

vzfirewall works with venet interfaces but not veth, it fails with the error:

Cannot find IP_ADDRESS in /etc/vz/conf/CTID.conf

At minimum we need to be able to skip these. In quick testing, veth traffic does cross the FORWARD iptables chain, so vzfirewall could be used to filter these containers as well.

Two approaches that come to mind are:

1. Support a commented out IP_ADDRESS field, just like FIREWALL is commented now.
2. Handle containers with no IP_ADDRESS differently, only supporting [custom] firewall rules, and the admin has to match destination ip addresses explicitly.

I might lean towards the first. Any preference/discussion before I being work on a patch?

[dimikot]

Personally, I like (2) a bit more. Because now there is only one single "convention" to work with vzfirewal - its "FIREWALL" section in *.conf (possibly commented - no matter; maybe in next OpenVZ versions mr. Belousov will add support for multiline options :-). If you introduce "#IP_ADDRESS", you add a second convention and, worse, REQUIRE this directive to be commented.

But (2) is not so good as well, because we have to repeat IP address again and again.

Is there a way to deal with veth MAC address instead of its IP address?

[jnorell]

In a quick search, it looks like iptables can match on mac addrs. The container config file has:

NETIF="ifname=eth0,mac=00:18:51:B9:72:EA,host_ifname=veth100110.0,host_mac=00:18:51:FB:E1:DB,vzbr0"

So we could find the mac addr there. On a related note, we might be able to match on the interface too (veth100110.0 in this case).

Another option might be to use another variable name for the IP address. I'm looking around at veth config setups to see if there's something standard, but something like VETH_IP_ADDRESS would work, as used at https://openvz.org/Using_private_IPs_for_Hardware_Nodes

[dimikot]

I believe the main veth benefit is that it's a "full-size" network interface device (in contrary to venet) which could be configured (and reconfigured) from inside a container. So it's unpredictable (theoretically) what IP address it really has (the IP address could change or be assigned from inside). On the other hand, MAC address could be a good candidate to stay constant, so, if iptables allows to specify MAC (or even the interface name - if it's more constant) in such case, it would be ideal to specify MAC IMHO.

[jnorell]

That's true .. it could even be a dhcp client with dynamic IP address.

Another scenario to consider is if the container has multiple IP addresses. Often you would only allow connections to specific services on certain addresses. For that either custom rules or a second iptables firewall inside the container (ie. not configured by vzfirewall) would be required.

How about this logic:

• If IP_ADDRESS is found, use it (current behavior).
• Otherwise if VETH_IP_ADDRESS is found, use it (ie. get the ip addrs there, otherwise same behavior).
• Otherwise, parse interface names from NETIF and specify the interface instead of ip address for firewall rules.

I think that last mode should be preferred least because of egress filtering. Ie. right now the FORWARD chain allows the container IP addrs as source and denies everything else - with the last mode you have to allow any source IP addr coming from the veth container, which potentially allows spoofing. But I don't think you have any choice for a dhcp client scenario, short of getting the ip address from the container after it's started (which we probably don't want to do).

[dimikot]

Looks fine.

[jnorell]

The VETH_IP_ADDRESS support was simple enough. I'm working on reading NETIF now.

As another example, I added two veth interfaces and the config file shows:

NETIF="ifname=eth0,bridge=vzbr0,mac=00:18:51:B9:72:EA,host_ifname=veth100110.0,host_mac=00:18:51:FB:E1:DB;ifname=eth1,bridge=vzbr0,mac=00:18:51:B9:72:FA,host_ifname=veth100110.1,host_mac=00:18:51:FB:E1:EB"

My current plan is pick out all host_ifname interfaces and add the FORWARD rules matching each.

[dimikot]

Great!

[jnorell]

In custom rule creation, $THIS gets changed to the ip address. In the case we only know the interface name, not ip addr, do we want to error when $THIS is encountered? Or should it substitute the interface name, so $THIS is either the ip or the interface depending on your setup? Or introduce a new substitution ($IFACE or somesuch)?

[dimikot]

I'd prefer an error message on inappropriate $THIS usage. We cannot substitute it by an interface name, because IP and interface name usage contexts differ significantly.

Plus a new $IFACE macro, yes.

[jnorell]

FWIW, I think there will be 2 macros needed, the bridge interface and the veth interface, so you can specify a rule such as:

-A FORWARD -m physdev --physdev-in veth101.0 -o br0 -j ACCEPT

Maybe use $IFACE and $BRIDGE.

[jnorell]

https://github.com/DmitryKoterov/vzfirewall/pull/9