RE: POSTROUTING hooks

RE: POSTROUTING hooks

[Eliot, Wireless and Server Administrator, Great Lakes Internet]

> -----Original Message-----
> From: Patrick Schaaf [mailto:bof@bof.de]
> Sent: Monday, June 05, 2006 1:25 PM
> To: Eliot, Wireless and Server Administrator, Great Lakes Internet
> Cc: Patrick Schaaf; Netfilter Development Mailinglist
> Subject: Re: POSTROUTING hooks
> 
> > So, given that the kernel keeps a mapping of the IP->MAC and the
packet
> > contains the destination IP, why can't we just look up the
destination
> > MAC for that IP in the kernel table, if it exists.
> 
> I think that's what destination MAC matching did, before it was
removed.
> 
> If I remember correctly, ARP stuff happens in a sufficiently different
> locking context from iptables processing, so nobody wanted to (could
> sanely)
> maintain an external access to the ARP structures just for the sake of
a
> destination MAC iptables match.
> 
> Maybe I misremember. Corrections welcome.
> 

I don't ever recall seeing destination MAC matching support. Do you know
what version of the code this was in?
 
Eliot Gable
Certified Wireless Network Administrator (CWNA)
Certified Wireless Security Professional (CWSP)
Cisco Certified Network Associate (CCNA)
CompTIA Security+ Certified
CompTIA Network+ Certified
Network and System Engineer
Great Lakes Internet, Inc.
112 North Howard
Croswell, MI 48422
(810) 679-3395
(877) 558-8324
 
Now offering Broadband Wireless Internet access in Croswell, Lexington,
Brown City, Yale, Worth Township, and Sandusky. Call for details.

Re: POSTROUTING hooks

[Patrick Schaaf]

> I don't ever recall seeing destination MAC matching support. Do you know
> what version of the code this was in?

Hmm. Google fails me. Maybe my memory completely failed me... Help, anybody? :)

best regards
  Patrick

Re: POSTROUTING hooks

[Philip Craig]

On 06/06/2006 04:37 PM, Patrick Schaaf wrote:
>> I don't ever recall seeing destination MAC matching support. Do you know
>> what version of the code this was in?
> 
> Hmm. Google fails me. Maybe my memory completely failed me... Help, anybody? :)

I found lots of talk about iptables dst mac matches, but no code.

ebtables can match on destination MAC.  This means you have to create
a dummy bridge though, which slows things down.

Another option is to create static arp entries, and then just filter
by IP address.

RE: POSTROUTING hooks

[Eliot, Wireless and Server Administrator, Great Lakes Internet]

> -----Original Message-----
> From: Patrick Schaaf [mailto:bof@bof.de]
> Sent: Monday, June 05, 2006 12:01 PM
> To: Eliot, Wireless and Server Administrator, Great Lakes Internet
> Cc: Netfilter Development Mailinglist
> Subject: Re: POSTROUTING hooks
> 
> > Where in the kernel's packet delivery process does the POSTROUTING
chain
> > hook in?
> 
> You can get a pretty accurate answer, for any kernel version, by doing
> 	grep NF_HOOK /usr/src/linux-whatever/net/ipv?/*.c
> 
> For the 2.4.18 kernel I'm looking at, there are three calls to
> NF_IP_POST_ROUTING in net/ipv4/ip_output.c. Two of them are
> obviously concerned with multicast, leaving one call in
> ip_finish_output.
> 
> So, POST_ROUTING is called when the packet leaves the IP stack.
> 
> As you can see there, only after POST_ROUTING is the packet queued
> to some network device. And only after that is ARP done, and only
> then is a destination MAC known (temporarily, until ARP changes
> something under your feet).
> 

Well, then how about we use a different approach. In my case, I don't
need to be guaranteed that the MAC address returned is the correct one
at all times. All I need to know is that it is very likely to be the
correct one.

So, given that the kernel keeps a mapping of the IP->MAC and the packet
contains the destination IP, why can't we just look up the destination
MAC for that IP in the kernel table, if it exists. Once the connection
is established this type of matching would work because ARP has already
happened for some packets on the network to this destination. Therefore,
there should be an entry in the table (assuming it has not already timed
out). 

Obviously, this only works when the router is on the destination network
that the destination IP is on. Also, this will obviously not match the
first packet sent to the destination IP (since ARP has not occurred). 

But, if the router is on the same network the destination IP is on, and
if ARP has already occurred, then this will give as good of an
estimation of what the destination MAC address is as is possible given
the circumstances. 

If we cannot look up the MAC, the module will not return a match. If we
cannot look up the MAC associated with the destination IP, we don't
match. We also don't do any active stuff to try to figure it out. This
would be a completely passive process. Only in certain circumstances
would this yield a result, but in those circumstances, it would be
extremely useful. In my case, it would give me what I needed. 

Is there anything flawed in this logic? Any other things about the Linux
kernel IP stack that might throw a kink in my plans?
 
Eliot Gable
Certified Wireless Network Administrator (CWNA)
Certified Wireless Security Professional (CWSP)
Cisco Certified Network Associate (CCNA)
CompTIA Security+ Certified
CompTIA Network+ Certified
Network and System Engineer
Great Lakes Internet, Inc.
112 North Howard
Croswell, MI 48422
(810) 679-3395
(877) 558-8324
 
Now offering Broadband Wireless Internet access in Croswell, Lexington,
Brown City, Yale, Worth Township, and Sandusky. Call for details.

Re: POSTROUTING hooks

[Patrick Schaaf]

> So, given that the kernel keeps a mapping of the IP->MAC and the packet
> contains the destination IP, why can't we just look up the destination
> MAC for that IP in the kernel table, if it exists.

I think that's what destination MAC matching did, before it was removed.

If I remember correctly, ARP stuff happens in a sufficiently different
locking context from iptables processing, so nobody wanted to (could sanely)
maintain an external access to the ARP structures just for the sake of a
destination MAC iptables match.

Maybe I misremember. Corrections welcome.

best regards
  Patrick

POSTROUTING hooks

[Eliot, Wireless and Server Administrator, Great Lakes Internet]

Where in the kernel's packet delivery process does the POSTROUTING chain
hook in? 

I'm trying to figure out how to write a module to allow matching on the
destination MAC address. From what I have been able to figure out so
far, it looks like the destination MAC is not actually set until right
before the packet goes out of the interface. Now, I have not been able
to find the code that would confirm this, so if anyone can point me to
the exact position where the destination MAC address is set, that would
be helpful. However, from what I have been able to observe with logging
and some quick and dirty modifications to a couple of modules to print
out some extra debugging info, this appears to be the case. 

What would it take to modify the Netfilter code to make the POSTROUTING
chain hook in AFTER the destination MAC is set, but BEFORE it gets sent
out the interface? 

If this change is made, what types of things might it break?

 
Eliot Gable
Certified Wireless Network Administrator (CWNA)
Certified Wireless Security Professional (CWSP)
Cisco Certified Network Associate (CCNA)
CompTIA Security+ Certified
CompTIA Network+ Certified
Network and System Engineer
Great Lakes Internet, Inc.
112 North Howard
Croswell, MI 48422
(810) 679-3395
(877) 558-8324
 
Now offering Broadband Wireless Internet access in Croswell, Lexington,
Brown City, Yale, Worth Township, and Sandusky. Call for details.

Re: POSTROUTING hooks

[Patrick Schaaf]

> Where in the kernel's packet delivery process does the POSTROUTING chain
> hook in? 

You can get a pretty accurate answer, for any kernel version, by doing
	grep NF_HOOK /usr/src/linux-whatever/net/ipv?/*.c

For the 2.4.18 kernel I'm looking at, there are three calls to
NF_IP_POST_ROUTING in net/ipv4/ip_output.c. Two of them are
obviously concerned with multicast, leaving one call in
ip_finish_output.

So, POST_ROUTING is called when the packet leaves the IP stack.

As you can see there, only after POST_ROUTING is the packet queued
to some network device. And only after that is ARP done, and only
then is a destination MAC known (temporarily, until ARP changes
something under your feet).

> I'm trying to figure out how to write a module to allow matching on the
> destination MAC address.

Impossible with the current setup, it seems. Which is probably the reason why
none of the 50 people who wanted to do that before, succeeded.

> What would it take to modify the Netfilter code to make the POSTROUTING
> chain hook in AFTER the destination MAC is set, but BEFORE it gets sent
> out the interface?

It would take a very brave person, with a masochistic streak, and
a burning desire to maintain his own Linux networking stack, device
drivers, and iptables derivate.

best regards
  Patrick

Re: POSTROUTING hooks

[Patrick McHardy]

Eliot, Wireless and Server Administrator, Great Lakes Internet wrote:
> Where in the kernel's packet delivery process does the POSTROUTING chain
> hook in? 
> 
> I'm trying to figure out how to write a module to allow matching on the
> destination MAC address. From what I have been able to figure out so
> far, it looks like the destination MAC is not actually set until right
> before the packet goes out of the interface. Now, I have not been able
> to find the code that would confirm this, so if anyone can point me to
> the exact position where the destination MAC address is set, that would
> be helpful. However, from what I have been able to observe with logging
> and some quick and dirty modifications to a couple of modules to print
> out some extra debugging info, this appears to be the case. 
> 
> What would it take to modify the Netfilter code to make the POSTROUTING
> chain hook in AFTER the destination MAC is set, but BEFORE it gets sent
> out the interface? 

Still doesn't help, ARP resolution happens after that.