Need to enable firewall-like features on the NAT64 #41

Closed
ydahhrk opened this Issue May 14, 2013 · 3 comments

Projects

None yet

2 participants

@ydahhrk
Member
ydahhrk commented May 14, 2013

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.

This was referenced Oct 28, 2013
@ydahhrk ydahhrk added a commit that referenced this issue Sep 19, 2014
@ydahhrk ydahhrk First revision of issue #41.
There's still some stuff to take care of, but I wanna merge first.
3013131
@ydahhrk ydahhrk added this to the 3.3.0 milestone Nov 4, 2014
@ydahhrk ydahhrk self-assigned this Nov 14, 2014
@ydahhrk ydahhrk added a commit that referenced this issue Dec 11, 2014
@ydahhrk ydahhrk Moving Jool from Prerouting to Local In, Local Out and Forwarding.
This is necessary so NAT64 happens after iptables does filtering.
It's also needed so Jool catches local traffic, which is needed by local CLATs.
As an added bonus, it invalidates issue #90. Woot!

Progress so far, summary:
- Issue #33: Done.
- Issue #41: Done.
- Issue #107: Done.
- Issue #111: dhfelix is done, but haven't even started to review.
- Issue #116: EAM done, moved from prerouting done, dummy interface done. Missing (off the top of my head):
	- Adapting the global packet processing pipeline for stateless mode.
	- Configuration options.
	- Review RFC 6145 and updaters.
- Issue #120: Done.
- Issue #121: Not done.

Everything needs testing. There are known bugs with fragmentation.
fa8b0c2
@ydahhrk
Member
ydahhrk commented Mar 3, 2015

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.

@ydahhrk ydahhrk removed this from the 3.3.0 milestone Mar 3, 2015
@ydahhrk ydahhrk removed their assignment Mar 3, 2015
@toreanderson
Contributor

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 ydahhrk modified the milestone: 4.0.0 Apr 13, 2015
@ydahhrk
Member
ydahhrk commented Nov 12, 2015

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.

@ydahhrk ydahhrk closed this Nov 12, 2015
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment