lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
Open Source and information security mailing list archives
| ||
|
Date: Tue, 20 Oct 2009 19:23:34 +0200 From: Guido Trotter <ultrotter@...qua.net> To: Atis Elsts <atis@...rotik.com> Cc: netdev@...r.kernel.org Subject: Re: Policy routing + route "via" gives a strange behavior On Tue, Oct 20, 2009 at 07:48:39PM +0300, Atis Elsts wrote: Hi, Thanks for your explanation/help! > > This is also refused unless a route like the one before appears in the > > default table, even though it does appear in table 100. Is this the right > > behavior, and if yes, why? > > I guess what you describe is too infrequent use case for anyone to really > care. Connected and link scoped routes are usually not added to policy > routing tables :) Can you explain more for what kind of setup this is needed? > What I'm using it to is to force virtual machine traffic from a host to be routed to a different interface (a gre interface, in my case). I set up a rule that traffic from the guests' network (or from their interfaces) looks up a different routing table, and in that table I set a default gateway so that any traffic the instance would do is sent via that gateway. > This "issue" could be solved by using routing table in the FIB lookup done in > fib_check_nh(). However, doing that would break a lot more setups than it > would "fix". > For example, if you had these rules > from all to 1.2.3.4 fwmark 0x64 lookup 100 > from all fwmark 0x64 unreachable > then adding policy route to table 100 would fail unless nexthop 1.2.3.4 was > used... > Not sure I follow you here, sorry! :/ How would it behave differently depending on the rules used? If in table 100 I had something like: ip route add 1.2.3.4 dev eth1 via 2.3.4.5 Then the traffic looking up 100 (which according to the rules is to 1.2.3.4, but could be to something else as well) must be routed via 2.3.4.5. Of course then in table 100 I need a route to 2.3.4.5, or I need one in the default table (which is the only one that gets checked now). > Anyway, you can achieve what you wish by using the "onlink" option, e.g.: > ip route add table 100 default dev eth1 via 192.168.5.254 onlink I will try this, thanks! What I was doing now was something like: ip route add 192.168.5.254/32 dev eth1 # no table 100 ip route add table 100 default dev eth1 via 192.168.5.254 ip route del 192.168.5.254/32 dev eth1 But it was kind of a nasty workaround. Although it was working :) Thanks, Guido -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to majordomo@...r.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Powered by blists - more mailing lists