Subject: Re: stf(4) and NAT
To: None <email@example.com>
From: Martijn van Buul <firstname.lastname@example.org>
Date: 11/24/2005 09:15:42
It occurred to me that Pavel Cahyna wrote in gmane.os.netbsd.devel.network:
> On Wed, Nov 23, 2005 at 09:06:09PM +0000, Martijn van Buul wrote:
>> It occurred to me that Pavel Cahyna wrote in gmane.os.netbsd.devel.network:
>> > I'm curious: how did the Livebox know what is the MAC address for
>> > s559154c5.adsl.wanadoo.nl on the local Ethernet segment?
>> Apperently, it didn't. I've powercycled the Livebox, and the only arp request
>> I see is it asking who 192.168.5.10 is.
> So it is sending to your MAC address packets with IP DST of
> s559154c5.adsl.wanadoo.nl without asking with ARP? Weird.
Yes. I'll try to see if I can somehow trigger it to send data to s55* before
it did an ARP for 192.168.5.10, but that might be a bit tricky.
> Maybe this is what the Livebox's "forwarding all incoming traffic" feature is
> actually expected to do?
Absolutely not. The livebox doesn't have a named feature like that at all;
what I did was make a NAT rule which rewrites "the address" to
192.168.5.10, and have the firewall apply it on all packets sent to the
mer0 interface (Which I assume to be the ADSL side of the modem; it does
have my public address) whose "address" is 188.8.131.52. And it does
seem to do this rewriting for at least *some* packet types - it seems
to do so for TCP, UDP, ICMP and GRE, but not for IPv6.
At first I thought that it might be related to multicast (As stf uses a
multicast ipv4 address), but it also does this with a "normal" gif tunnel,
which uses the same IP packet type, as I found out after resurrecting my
existing (but with a bit of bad luck: soon to be dying) static IPv6 tunnel.
The Livebox firewall only "knows about" a few IP packet types. From the top
of my head: IP, TCP, ICMP, GRE, UDP, AH, CQ and another one (ESP? I forgot,
can't check right now). Oh yes, and "Any". I'm having a nagging suspicion that
it has some issues with NATting "unknown" packet types, although the reason
why eludes me.
 It doesn't state whether it will rewrite the destination or the
target address. It took me some time to figure out that "to" and "from"
didn't mean "destination" and "source", but are used to indicate a range..
 See . The net result *appears* to be what would be a binat rule in
terms of ipf's ipnat.
Martijn van Buul - email@example.com - http://www.stack.nl/~martijnb/
Geek code: G-- - Visit OuterSpace: mud.stack.nl 3333
The most exciting phrase to hear in science, the one that heralds new
discoveries, is not 'Eureka!' (I found it!) but 'That's funny ...' Isaac Asimov