2001-02-17 01:41:11

by Jack Bowling

[permalink] [raw]
Subject: too long mac address for --mac-source netfilter option

I am trying to use the --mac-source option in the netfilter code to better refine access to my linux box. However, I have run up against something. The router through which my private subnet work box passes sends a 14-group "invalid" mac address, presumably as an attempt to conceal the real hextile mac address. However, the code for the --mac-source netfilter option is looking for a valid hextile mac address and complains loudly as such (numerals converted to x's):

iptables v1.1.1: Bad mac address `xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx'

to the respective iptable line:

$IPT -A INPUT -p tcp -s xxx.xxx.xxx.xxx -d $NET -m mac --mac-source xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx --dport 5900:5901 -j ACCEPT

The idea here is to allow VNC access to my home box with the access filtered by both IP and mac address.

Is there a resolution to this other than a rewrite and recompile of the relevant sections of the iptable code? Or am I stuck? I know this option is tagged by Rusty as experimental still so I would assume that the code is open for feedback ;) The question could be rephrased as: is there any chance of allowing "invalid" mac addresses to be recognized by the --mac-source option of the netfilter code? Running Redhat v7/kernel 2.4.1-ac15.

Jack Bowling
mailto: [email protected]







2001-02-17 02:09:45

by Mr. James W. Laferriere

[permalink] [raw]
Subject: Re: too long mac address for --mac-source netfilter option


Hello Jack & All , Might this be an atm interface ?
If it is not then am I to assume that an atm interface
with its erroneous mac-address is going to have the same
difficulties . That is of course as soon as the atm interface
actually put a valid ESI/mac-address into the interface table .
Tia , JimL

On Fri, 16 Feb 2001, Jack Bowling wrote:
>> I am trying to use the --mac-source option in the netfilter code to
>better refine access to my linux box. However, I have run up against
>something. The router through which my private subnet work box passes
>sends a 14-group "invalid" mac address, presumably as an attempt to
>conceal the real hextile mac address. However, the code for the
>--mac-source netfilter option is looking for a valid hextile mac address
>and complains loudly as such (numerals converted to x's):
> iptables v1.1.1: Bad mac address `xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx'
> to the respective iptable line:
>> $IPT -A INPUT -p tcp -s xxx.xxx.xxx.xxx -d $NET -m mac --mac-source
>xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx --dport 5900:5901 -j ACCEPT
>> The idea here is to allow VNC access to my home box with the access
>filtered by both IP and mac address.
>> Is there a resolution to this other than a rewrite and recompile of the
>relevant sections of the iptable code? Or am I stuck? I know this option
>is tagged by Rusty as experimental still so I would assume that the code
>is open for feedback ;) The question could be rephrased as: is there any
>chance of allowing "invalid" mac addresses to be recognized by the
>--mac-source option of the netfilter code? Running Redhat v7/kernel
>2.4.1-ac15.

+----------------------------------------------------------------+
| James W. Laferriere | System Techniques | Give me VMS |
| Network Engineer | 25416 22nd So | Give me Linux |
| [email protected] | DesMoines WA 98198 | only on AXP |
+----------------------------------------------------------------+

2001-02-17 10:51:16

by Stefan Smietanowski

[permalink] [raw]
Subject: Re: too long mac address for --mac-source netfilter option

Hi!
> I am trying to use the --mac-source option in the netfilter code to better refine access to my linux box. However, I > have run up against something. The router through which my private subnet work box passes sends a 14-group "invalid" > mac address, presumably as an attempt to conceal the real hextile mac address. However, the code for the > --mac-source netfilter option is looking for a valid hextile mac address and complains loudly as such (numerals converted to x's):
>
> iptables v1.1.1: Bad mac address `xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx'
>
> to the respective iptable line:
>
> $IPT -A INPUT -p tcp -s xxx.xxx.xxx.xxx -d $NET -m mac --mac-source xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx --dport 5900:5901 -j ACCEPT
>
> The idea here is to allow VNC access to my home box with the access filtered by both IP and mac address.
>
> Is there a resolution to this other than a rewrite and recompile of the relevant sections of the iptable code? Or am I stuck? I know this option is tagged by Rusty as experimental still so I would assume that the code is open for feedback ;) The question could be rephrased as: is there any chance of allowing "invalid" mac addresses to be recognized by the --mac-source option of the netfilter code? Running Redhat v7/kernel 2.4.1-ac15.

Umm.. An ethernet MAC address is 48bit long, ie AA:BB:CC:DD:EE:FF, 6
groups, not 14. Is this really an ethernet
interface? (If it really has 14 groups).

// Stefan

2001-02-18 18:30:13

by Harald Welte

[permalink] [raw]
Subject: Re: too long mac address for --mac-source netfilter option

On Fri, Feb 16, 2001 at 05:40:04PM -0800, Jack Bowling wrote:
> I am trying to use the --mac-source option in the netfilter code to better
> refine access to my linux box. However, I have run up against something. The
> router through which my private subnet work box passes sends a 14-group
> "invalid" mac address, presumably as an attempt to conceal the real hextile
> mac address. However, the code for the --mac-source netfilter option is
> looking for a valid hextile mac address and complains loudly as such
> (numerals converted to x's):
>
> iptables v1.1.1: Bad mac address `xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx'
>
> to the respective iptable line:
>
> $IPT -A INPUT -p tcp -s xxx.xxx.xxx.xxx -d $NET -m mac --mac-source
> xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx --dport 5900:5901 -j ACCEPT
>
> The idea here is to allow VNC access to my home box with the access filtered
> by both IP and mac address.

This is not a bug. It is by intention. The LOG target (as well as the
ULOG target from netfilter CVS) prints the whole layer two header.

6 bytes mac-source, 6 bytes mac-destination and 2 bytes (08:00) indicating
it is IP. == 14 bytes :)

On the other hand, the --mac-source match (emphasized mac-SOURCE) allows
you to match on the source part of this mac header (i.e. the first 6 bytes)

> Jack Bowling
> mailto: [email protected]

--
Live long and prosper
- Harald Welte / [email protected] http://www.gnumonks.org
============================================================================
GCS/E/IT d- s-: a-- C+++ UL++++$ P+++ L++++$ E--- W- N++ o? K- w--- O- M-
V-- PS+ PE-- Y+ PGP++ t++ 5-- !X !R tv-- b+++ DI? !D G+ e* h+ r% y+(*)