Re: NAT

>>>>> Pascal Hambourg <pascal.mail@plouf.fr.eu.org> writes:
>>>>> Ivan Shmakov a écrit :
>>>>> Pascal Hambourg <pascal.mail@plouf.fr.eu.org> writes:

>>> [...] although IPv6 NAT could be a helpful quick and dirty hack in
>>> a some situations (e. g. source NAT to work around some flaws in
>>> the source address selection).

>> Couldn't ip(8) be used for that?

> Last time I checked, the 'src' option in IPv6 routes was ignored.

To be honest, I don't know for sure.

>> $ /sbin/ip route show table myvpn

>> default via <IPv4> dev <Tunnel-Iface>

>> This rule makes all the packets for which this table was invoked to
>> be routed through <Tunnel-Iface>...

>> default dev <Tunnel-Iface> scope link src <IPv4>

>> ... and this one apparently alters the source address selection.

> Err... Aren't these two routes to the same destination, and thus
> conflicting with each other ?

Apparently, they're not.

IIUC, the first rule means, in pseudocode:

if (destination: default, nexthop: <IPv4>) {
set! output-device: <Tunnel-Iface>;
}

While the second one:

if (destination: default, scope: link) {
set! output-device: <Tunnel-Iface>,
source: <IPv4>;
}

Thus, the second rule only applies to the packets being OUTPUT
(because of scope: link), while the first one applies only to
the packets being FORWARDED.

> In that situation the kernel will use only one (if ask me which one,
> I'll say either, don't rely on it).

>> For the more complicated cases, some ``mark'' (fwmark?) selector
>> could be used in conjunction with iptables-based marking of packets.

> Unfortunaltey the netfilter mark comes too late, after the source
> address selection is performed. Source address selection is
> performed when the packet is created, before it enters the OUTPUT
> chains where marking takes place. So there is a rerouting after
> OUTPUT to take the mark or destination address change into account
> and update the routing, but the source address is not updated.

Agreed. As I've said before, I'm not quite keen at ip(8) yet.
(After all, I'm using it for only a few days.)

--
FSF associate member #7257

--
To UNSUBSCRIBE, email to debian-firewall-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org