Page MenuHomeVyOS Platform

MAC address as source for conntrack timeouts
Open, LowPublic

Description

I'd like to implement MAC addresses as a possible source for custom timeout rules. Right now, the only options are IP addresses and ports:

vyos@vyos# set system conntrack timeout custom ipv4 rule 1 source
Possible completions:
    address		IP address, subnet, or range
    port		Port number

In the old iptables, MAC address timeout rules can be easily created using the NFCT utility from conntrack-tools. I'd like to replicate this functionality in VyOS.

For example, in the old iptables, you can do this:

# Create named timeout policies
nfct add timeout dns4 inet udp unreplied 180 replied 180
nfct add timeout dns6 inet6 udp unreplied 180 replied 180

# Create firewall rules that reference the above policies
iptables --insert PREROUTING -t raw -p udp -m mac --mac-source 01:02:03:04:05:06 --dport 53 --in-interface eth1 -j CT --timeout dns4
ip6tables --insert PREROUTING -t raw -p udp -m mac --mac-source 01:02:03:04:05:06 --dport 53 --in-interface eth1 -j CT --timeout dns6

You can also create in-memory hash tables to efficiently match multiple MAC addresses:

ipset create SERVER_MACS hash:mac
ipset add SERVER_MACS 01:02:03:04:05:06
ipset add SERVER_MACS 01:02:03:04:05:07
ipset add SERVER_MACS 01:02:03:04:05:08
ipset add SERVER_MACS 01:02:03:04:05:09

iptables -I PREROUTING -t raw -p udp --dport 53 --in-interface eth1 -m set --match-set SERVER_MACS src -j CT --timeout dns4
ip6tables -I PREROUTING -t raw -p udp --dport 53 --in-interface eth1 -m set --match-set SERVER_MACS src -j CT --timeout dns6

As you can see, with MAC addresses, the exact same rules can be created for both the IPv4 firewall and the IPv6 firewall.

This is a huge advantage of MAC addresses - the administrator does not need to know or care what the source IP is, or whether IPv4 or IPv6 is used. This will be especially useful as IPv6 continues to gain traction, because publicly-routable GUAs are notoriously difficult to predict. The prefix is unpredictable because your ISP can change it at any time, and the suffix is unpredictable because randomly-generated temporary addresses are used for all outbound traffic instead of the stable IPv6 host address. Therefore, to uniquely match a host sending Internet-bound traffic via IPv6, we need to use some other identifier within the packet header besides the IP address. That leaves us with the MAC address - an excellent candidate.

Due to the nature of IPv6, there are no good ways to implement policies like this at layer 3. You can statically assign a ULA to the host interface, but ULA addresses are only used for internal communication. On a NIC with both a GUA and ULA, the GUA will always be used for outbound communication to the Internet. You can't statically assign a GUA to a host interface, because if the ISP-assigned prefix changes, the host will lose Internet connectivity.

But MAC addresses are permanent and constant, regardless of what higher-layer protocols are in use. MAC addresses are not guaranteed to be globally unique, despite the industry's best efforts. But they MUST be unique within a VLAN in order for that network to properly function without conflicts. That's why I've also included the --in-interface eth1 in my examples. Checking that both the MAC address and the inbound router interface match would guarantee matching with the correct internal host, because the MAC must already be unique in that subnet anyway.

The only way a MAC address rule like this wouldn't work is if there are one or more intermediate routers between the host and THIS router. But a network administrator would easily be able to determine this, and they would be able to implement an alternate policy for that situation.

Details

Version
-
Is it a breaking change?
Unspecified (possibly destroys the router)
Issue type
Feature (new functionality)