Need to enable firewall-like features on the NAT64

[ydahhrk]

Test case ID: N/A
Date: 2013/05/13
OS: N/A
Tester: -
Error module: filtering
Description: The user needs a way to define policies to control whether BIB and session entries are created or not. At this point, the module calls an empty function.
Observations: The RFC does not define the policies; they are expected to be user-defined. I imagine the NAT64 is supposed to work like iptables, in the sense that other kernel modules can be attached to it and apply logic.

Jool intercepts and steals packets before iptables filters, so there's no way to firewall translating traffic unless it is done by a separate, adjacent machine.

[ydahhrk]

The changes we planned proved to be insufficient.

This will remain an open issue in Jool 3.3.

This is another problem that would probably be naturally and indirectly fixed by turning Jool into a device driver.

[toreanderson]

Jool intercepts and steals packets before iptables filters, so there's no way to firewall translating traffic unless it is done by a separate, adjacent machine.

As I've mentioned before in e-mail, this isn't actually the case. Jool does steal the packet so that it doesn't traverse IPTables' filter table, but you can still access the packet prior to translation in PREROUTING chain of the mangle table, or after translation in the POSTROUTING chain.

So you can do stuff like this:

### IPv6 -> IPv4 direction
# Block ICMPv6 (e.g., echo requests) destined for 192.0.2.1 before Jool grabs the packet
ip6tables -t mangle -I PREROUTING -d 64:ff9b::192.0.2.1 -p icmpv6 -j DROP
# Same, but let the packet pass through Jool for translation before dropping it
iptables -t mangle -I POSTROUTING -d 192.0.2.1 -p icmp -j DROP

### IPv4 -> IPv6 direction
# Drop ICMPv4 (e.g., echo replies) from 192.0.2.1 before Jool grabs the packet
iptables -t mangle -I PREROUTING -s 192.0.2.1 -p icmp -j DROP
# Same, but let the packet pass through Jool before dropping it
sudo ip6tables -t mangle -I POSTROUTING -s 64:ff9b::192.0.2.1 -p icmpv6 -j DROP

Another thing worth pointing out is that any marks set on the packet in the PREROUTING chain survive the translation by Jool and are available for matching in the POSTROUTING chain. This allows you to overcome certain limitations of using the PRE- and POSTROUTING chains, such as not being able to match on the input interface in the POSTROUTING chains. For example:

# Mark (IPv4) packets arriving on interface eth0 with the value 0x42
iptables -t mangle -I PREROUTING -i eth0 -j MARK --set-mark 0x42
# Now we can check for that mark in the (IPv6) POSTROUTING chain
ip6tables -t mangle -I POSTROUTING -m mark --mark 0x42 -j DROP

If you don't want to use IPTables, there's also an alternate way you can block traffic using ip rule, e.g.:

# Drop outgoing IPv4 packets with dst=192.0.2.1 (after Jool has translated it from IPv6):
ip -4 rule add to 192.0.2.1 prohibit
# Similarly, drop outgoing IPv6 packets with src=64:ff9b::192.0.2.1 dst=2001:db8::1
ip -6 rule add from 64:ff9b::192.0.2.1 to 2001:db8::1 prohibit

Note that filtering using ip rule in this way is more limited than using IPTables, as it only allows you to match on Layer 3 headers (no TCP/UDP ports etc.), and it can only filter after Jool has translated a packet. However if those constraints are fine, then ip rule is probably more lightweight than IPTables, because ip rule hooks into the kernel's routing infrastructure, which needs to process every packet anyway, while IPTables is completely optional; you can run Jool just fine without having any of the IPTables kernel modules loaded.

In summary I think this is more of a documentation issue, not a missing feature. At least I don't see any point in duplicating functionality provided by other parts of the kernel in Jool itself.

[ydahhrk]

OK, here's the status:

As I said in this comment, I do not see any problems with filtering in mangle, but some iptables documentation does (apparently). I do not know the reasoning, so I will neither discourage nor encourage it.

On the other hand, now that Jool can be enclosed in a namespace, filtering can be done in the forwarding chains. This might not look as clean as it could be, but is no different than if Jool were a device driver.

So either way, it looks like this is no longer an issue.

Closing.