4

As far as i know, there is no way of distinguishing VLAN traffic in iptables on the master interface (that is the interface to which virtual VLAN interfaces are added with vconfig or ip link add link; I don't know if that's the correct term, I encourage you to correct me).

In general that's no problem, as you can match using the virtual VLAN interface instead of the master interface, e.g.

iptables -A INPUT -i eth0.1 -p tcp -m tcp --dport 22 -j ACCEPT

This will allow TCP port 22 (SSH) packets arriving on eth0.1, which are packets arriving on eth0 tagged with VLAN-ID 1.

Problems arise, when you want to match only untagged traffic on the master interface, e.g.

iptables -A INPUT -i eth0 -p tcp -m tcp --dport 53 -j ACCEPT

Our intend is to match TCP port 53 (DNS) packets arriving on eth0 without a VLAN tag, which we do, but we also match packets with any other VLAN-Tag arriving on eth0.

So a possibly workaround would be to include the IP address/subnet of the master interface in the rule. Let's assume we are using 10.0.0.0/24 on eth0 and 10.0.1.0/24 on eth0.1:

iptables -A INPUT -i eth0 -d 10.0.0.0/24 -p tcp -m tcp --dport 53 -j ACCEPT

Unfortunately this has two drawbacks:

  1. We are also matching packets with bogus IP address, nothing stops malicious or misconfigured clients to send packets with 10.0.0.0/24 and VLAN-ID 1. In general that should not be an issue, because answers to that packet will take another route back and won't reach the original
  2. It does not work with broadcast traffic, like DHCP for example, which does not use the interface's IP address.

Especially the latter problem bothers me. For example the following has unwanted side effects:

iptables -A INPUT -i eth0 -p udp -m udp --dport 67 -j ACCEPT

This rule will match any incoming DHCP traffic on eth0, regardless which VLAN-tag a packet has on. If we want to exclude DHCP traffic with VLAN-ID 1, we are lost.

Any suggestions?

Sebastian Schrader
  • 540
  • 1
  • 4
  • 11

3 Answers3

3

I don't think your problem is iptables. I have several boxes acting as routers between VLAN's and I match untagged traffic as you have explained you are trying to do without any problems.

I just tested, I can DROP all traffic on the untagged interface without affecting the tagged interface traffic:

# iptables -A FORWARD -i eth0 -j DROP
# ping -nc3 192.168.100.129
PING 192.168.100.129 (192.168.100.129) 56(84) bytes of data.
64 bytes from 192.168.100.129: icmp_seq=1 ttl=64 time=0.180 ms
64 bytes from 192.168.100.129: icmp_seq=2 ttl=64 time=0.176 ms
64 bytes from 192.168.100.129: icmp_seq=3 ttl=64 time=0.153 ms

--- 192.168.100.129 ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 1998ms
rtt min/avg/max/mdev = 0.153/0.169/0.180/0.019 ms

(192.168.100.129 exists in VLAN 10 / eth0.10)

I think there is either an error in your configuration, or a bug somewhere.

fukawi2
  • 5,396
  • 3
  • 32
  • 51
  • Only if you have -A FORWARD -i eth0.10 -j ACCEPT beforehand, otherwise eth0.10 traffic will match against eth0 and become dropped. – Milos Ivanovic Aug 05 '15 at 16:48
1

iptables works on a layer too high in the network stack to properly look at vlans, I'm actually surprised that -i eth0.1 works :)

Have a look at ebtables, which works on ethernet frames and can either do the filtering itself or set marks to be used by iptables.

Something like this untested snippet should get you started:

ebtables -A INPUT --vlan-id ! 1 --jump mark --mark-set 0xff
iptables -A INPUT -i eth0 -p udp -m udp --dport 67 -m mark ! --mark 0xff -j ACCEPT
Dennis Kaarsemaker
  • 19,277
  • 2
  • 44
  • 70
0

I think you should use the physical interface only as a physical layer. You don't assign any IP address to this interface but instead, you create virtual interfaces bounded to eth0 which will take care of the IP transport.

Spack
  • 1,604
  • 15
  • 22
  • Would you mind explaining that in more detail? – Hauke Laging May 05 '13 at 00:30
  • @HaukeLaging what is the network configuration you want to achieve? – Spack May 05 '13 at 09:09
  • Simply with respect to the OP's problem. I read his question and your answer and don't see how your answer can help him practically. Maybe it can but there is too little information for me to comprehend it. – Hauke Laging May 05 '13 at 11:48
  • According to the top answer to this [question](http://serverfault.com/questions/167609/iptables-ip-alias-and-port-forwarding), `iptables` does not recognize alias interfaces, it will just use the normal interface instead, like `tcpdump` does too. But maybe that answer is wrong, I will try your suggestion. However, I would prefer another solution, as the use of alias interfaces is discouraged and superseded by `ip addr`. – Sebastian Schrader May 05 '13 at 16:48
  • Just tested it using `iptables -I INPUT -i eth0:0 -j LOG` does not produce any log entries, so matching an alias interface is not possible. This is also stated in the last question [here](http://rocky.eld.leidenuniv.nl/joomla/index.php?option=com_content&view=article&id=50&Itemid=81). – Sebastian Schrader May 05 '13 at 20:26