Konstantin Ushakov wrote:
Patrick McHardy wrote:
Questions:
- is it a bug or it's a deliberate decision to have such behaviour?
- is there any known add-hock solution for the problem?
Its a consequence of how routing by fwmark works. Its not perfect,
but I don't see a better solution since the initial routing takes
place before we even have a packet.
Just add a route to the dummy device or something like that, that
should make sure you don't get ENETUNREACH.
I'm afraid that dummy route does not solve the problem. I mean
- we should not pass out the packets, so where should the route lead?
To loopback?
As I said, to the dummy device.
- another thing is that on 'send' (for, say, some external address,
port 239)
with dummy route we hang, but if in fact the packet can't be routed,
we should get ENETUNREACH.
[...]
Idea that we had is the following:
we mark all packets that have passed netfilter (mangle table) with a
specific mark (see configuration below).
We add 2 rules:
- unreachable, for packets that have passed mange table but should not
be routed
- rule that lookup table #100 for all packets, in table #100 we have
route like
ip route add default via 127.0.0.2 table 100
Local traffic that goes to tcp port 80 is routed correctly. Forwarded
traffic is not routed,
ENETUNREACH is received on the lan side. BUT for local traffic that
should not be forwarded,
we don't receive UNREACH, 'send' just hangs.
Example:
on host on LAN side of the router:
bash$ nc 192.168.1.5 81
(UNKNOWN) [192.168.1.5] 80 (www) : No route to host
BUT if we issue that same command on the router itself, it handgs.
Ah, I see the problem. The route returns unreachable, which
iptable_mangle translates to NF_DROP. The problem is that
netfilter itself can't return ENETUNREACH and there is no
valid output function attached to the dst_entry that would
send an icmp unreachable. I think the only thing you could
do is manually call icmp_send(ICMP_DEST_UNREACH) in
ip_route_me_harder for this case.
-
To unsubscribe from this list: send the line "unsubscribe netfilter-devel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
