# firewalling generic question about ... filtering

## doublehp

Hello.

Here is the core part of my script; it runs without any error message:

```
for i in FORWARD OUTPUT

do

        for j in $masc

        do

                $EBTABLES -A $i -d $j -o tap0 -j ACCEPT

        done

        for j in $ip4s

        do

                $EBTABLES -A $i -o tap0 -p ARP --arp-ip-dst ! ${j} -j DROP

        done

        for j in $ip6s

        do

                $IP6TABLES -A $i -o tap0 -p icmpv6 -d $j -j ACCEPT

        done

        $IP6TABLES -A $i -o tap0 -p icmpv6 -j DROP

done

```

This host, let say server S, only has physical eth0; then VPN on tap0, and both are bridged on br0. So, only br0 has an IP. My aim here is to filter traffic on the VPN. The VPN has only one client, let say C. ip4s and ip6s and macs are the lists of the clien specifications. For IPv4, then IPv6, I first allow network discovery for the VPN client (si that people in the LAN can detect C), then block the generic discoveries (I don't need to send on the VPN the querries when S probes other machines on the LAN; and I don't need to forware to the VPN the LAN discoveries that are not about C).

Now, I run tcpdump on C, and I see those two groups of logs which, IMHO, should not have traveled via the VPN:

```
02:03:14.408841 00:01:03:0c:3d:11 > 33:33:ff:3c:cd:22, ethertype IPv6 (0x86dd), length 86: (hlim 255, next-header ICMPv6 (58) payload length: 32) fe80::201:3ff:fe0c:3d11 > ff02::1:ff3c:cd22: [icmp6 sum ok] ICMP6, neighbor solicitation, length 32, who has fe80::20e:a6ff:fe3c:cd22

          source link-address option (1), length 8 (1): 00:01:03:0c:3d:11
```

where 00:01:03:0c:3d:11 is S, and 33:33:ff:3c:cd:22 a random host on the LAN. I understand that S may need to run discoveries, and need to send them on br0. But IMHO this packet should match

$IP6TABLES -A $i -o tap0 -p icmpv6 -j DROP

and should be dropped.

1: Why not ? How do I drop it ?

2: what is this, and how do I cleverly drop it ?

```
02:02:34.341397 6c:f0:49:02:21:33 > ff:ff:ff:ff:ff:ff, ethertype Unknown (0x88a2), length 60:

        0x0000:  1000 ffff ff01 0000 0000 0000 0000 0000  ..ÿÿÿ...........

        0x0010:  0000 0000 0000 0000 0000 0000 0000 0000  ................

        0x0020:  0000 0000 0000 0000 0000 0000 0000       ..............
```

where 6c:f0:49:02:21:33 is a random host in the LAN. This packet comes in via eth0,  and the bridge forwards it to tap0; that's expected. But I don't understand why this host sends this, and I am 99% certain I don't need this for C; how do I drop this the clean way ?

3: I also have a lot of those

```
02:01:55.304287 6c:f0:49:02:21:33 > 01:00:5e:7f:ff:fa, ethertype IPv4 (0x0800), length 557: (tos 0x0, ttl 4, id 0, offset 0, flags [DF], proto UDP (17), length 543) 192.168.246.152.37648 > 239.255.255.250.1900: UDP, length 515

[...]

02:03:19.488766 00:07:cb:0f:28:44 > 01:00:5e:7f:ff:fa, ethertype IPv4 (0x0800), length 313: (tos 0x0, ttl 2, id 0, offset 0, flags [DF], proto UDP (17), length 299) 192.168.246.1.1900 > 239.255.255.250.1900: UDP, length 271
```

with various length values, coming mostly from those two hosts, and, same as question 2: probably useless for C, so, wanna drop.

4: what is 01:00:5e:7f:ff:fa ? no host in my network has such a MAC; so, looks to me as a generic MAC, some kind of broadcast, like 33:33:ff:3c:cd:22. What is 239.255.255.250.1900: UDP ? Google says it's about UPNP discovery, but from memory, this IP is not in APIPA. If it helps, I use SIP, and various TV broadcasting systems (rtsp and MediaTomb amongst other things).

Thanks.

----------

## truc

What about a nice ascii art to show us your configuration(this can help)

----------

## kerframil

In response to question #1, you may need to use the physdev helper module (see below).

In response to question #2, this is AoE (ATA over Ethernet) traffic. You should be able to match it in ebtables with -p 0x88a2. Other options are to disable ATA over Ethernet, refrain from loading the module, or limit the interfaces used for AoE by writing the interface names to /sys/module/aoe/parameters/aoe_iflist (for all applicable hosts).

In response to question #3, try using an iptables rule such as this:

```
-A FORWARD -m physdev --physdev-out tap0 -m pkttype --pkttype multicast -j DROP
```

Note that the use of the physdev module is important when acting on bridged traffic. Its usage also assumes that CONFIG_BRIDGE_NETFILTER is enabled in the kernel.

In response to question #4, the 01:00:5e namespace is reserved by IANA for multicast. 239.255.255.250 is a multicast group address where 239/8 is reserved for private usage (see RFC 2365). In this case, you're looking at the SSDP protocol. In iptables, you can easily match multicast traffic with the pkttype and addrtype helper modules.

----------

## doublehp

I don't know which device is providing or asking for AoE; and since the packet is using broadcast ... I know of course the first mac, but this does not tell me why this host is sending this packet. It's an other host in the LAN.

----------

## kerframil

 *doublehp wrote:*   

> I don't know which device is providing or asking for AoE; and since the packet is using broadcast ... I know of course the first mac, but this does not tell me why this host is sending this packet. It's an other host in the LAN.

 

You could use the following ebtables rule then:

```
-A FORWARD -p 0x88a2 -j DROP
```

----------

## doublehp

Thank you very much for tips. No time to hack this right now, but, when I'll have time, I know I can fix my bridge  :Smile:  (aka, save some bandwidth)

----------

## doublehp

A new strange frame:

```
03:05:29.238817 00:20:00:6f:8b:f5 > ff:ff:ff:ff:ff:ff, ethertype NS (0x0600), length 64:

        0x0000:  0000 f581 8000 0000 0000 0000 0000 0000  ..õ.............

        0x0010:  0000 0000 0000 0000 0000 0000 0000 000f  ................

        0x0020:  0001 030c 3d5b 0011 9506 ee3c 0806 0001  ....=[....î<....

        0x0030:  0800                                     ..

```

It comes out of a Lexmark (so called) "smart" printer (printer, scanner, fax and so on) (in practice, I could never make a single page come out of it; but it's not me who decided to buy it). Since 0x88a2 was not in /etc/ethertypes but you mentionned it was AoE, I found that your statement are confirmed by http://en.wikipedia.org/wiki/EtherType . But ... the Wiki does not say anything about 0x0600 ... I know how to filter it now, but I still wonder what this packet is about :/

Slowly reducing my VPN iddle traffic  :Smile: 

----------

## doublehp

1y later ...

$IPTABLES -A $i -m physdev --physdev-out tap0 -m pkttype --pkttype multicast -j DROP

=>

iptables v1.4.0: Unknown arg `--pkttype'

is it a recent option ?

----------

## doublehp

I did not dig in this issue. The machine does the job, so I don't worry about this for now.

----------

