| Message ID | 1441806352-18030-2-git-send-email-dedeckeh@gmail.com |
|---|---|
| State | Accepted |
| Headers | show |
Hi, On Wed, Sep 9, 2015 at 3:45 PM, Hans Dedecker <dedeckeh@gmail.com> wrote: > Specific IP address and network rules are now checked before the main table lookup as the main table > often holds a default route. As a result the IP address and network rules pointing to s specific > routing table will not be checked anymore; by reversing the order the specific routing tables > are checked first if the ip rule matches. This commit breaks existing behavior in the following use case: A multihomed router with some service available on one of the external interfaces that should be reachable on the WAN. The destination routing works fine, but replies are sent out on the wrong interface. The reason is that the nw rule is checked before main, so packets are routed back out on the WAN interface (and not to the LAN). I don't see any other fix than a partial revert. I guess the ADDR-rule can stay. -Kristian
On Wed, Sep 23, 2015 at 9:50 AM, Kristian Evensen < kristian.evensen@gmail.com> wrote: > Hi, > > On Wed, Sep 9, 2015 at 3:45 PM, Hans Dedecker <dedeckeh@gmail.com> wrote: > > Specific IP address and network rules are now checked before the main > table lookup as the main table > > often holds a default route. As a result the IP address and network > rules pointing to s specific > > routing table will not be checked anymore; by reversing the order the > specific routing tables > > are checked first if the ip rule matches. > > This commit breaks existing behavior in the following use case: > > A multihomed router with some service available on one of the external > interfaces that should be reachable on the WAN. The destination routing works fine, but replies are sent out on the wrong interface. > The reason is that the nw rule is checked before main, so packets are > routed back out on the WAN interface (and not to the LAN). Can you share the uci network config and ifstatus of the different interfaces ? > > I don't see any other fix than a partial revert. I guess the ADDR-rule can > stay. Is the service hosted on the multihomed router or on a lan device; nat involved or not ? It seems odd to me if the service is hosted on the gateway the nw rule is hit as the local table lookup has pref 1 while the NW policy rules start from 20000 Hans > > -Kristian >
Sorry about partial reply, clumsy fingers. On Wed, Sep 23, 2015 at 11:31 AM, Hans Dedecker <dedeckeh@gmail.com> wrote: > Can you share the uci network config and ifstatus of the different > interfaces ? UCI config is nothing more than ... proto dhcp ... ip4/ip6table X >> >> >> I don't see any other fix than a partial revert. I guess the ADDR-rule can >> stay. > > Is the service hosted on the multihomed router or on a lan device; nat > involved or not ? The current service I am access is a router located on one of the external networks. > It seems odd to me if the service is hosted on the gateway the nw rule is > hit as the local table lookup has pref 1 while the NW policy rules start > from 20000 The route that needs to be hit is contained in main. Here is a more detailed description of what happens. - External router has IP 192.168.0.1 and netmask 255.255.255.0. - When I try to access this router, outgoing traffic is routed correctly as it does not match any source rules and hit the network rule in the main table (192.168.0.0/24 dev X src Y). - When the reply comes, problem occurs. Since the network rule is checked before the main table, we get a match on the "from 192.168.0.0/24"-rule and packet is routed back out on the 192.168.0.0/24 interface. The correct route (i.e., the route for my local network) is in the main table. I have a question about this patch. In what scenario is it needed? Or rather, will you ever use source based routing and have a default route in the main table? As far as I remember, these rules are only added when you have specified an ip4/ip6table. Or do you have one interface without an ipXtable value? -Kristian
On Wed, Sep 23, 2015 at 11:52 AM, Kristian Evensen < kristian.evensen@gmail.com> wrote: > Sorry about partial reply, clumsy fingers. > > On Wed, Sep 23, 2015 at 11:31 AM, Hans Dedecker <dedeckeh@gmail.com> > wrote: > > Can you share the uci network config and ifstatus of the different > > interfaces ? > > UCI config is nothing more than ... proto dhcp ... ip4/ip6table X > > >> > >> > >> I don't see any other fix than a partial revert. I guess the ADDR-rule > can > >> stay. > > > > Is the service hosted on the multihomed router or on a lan device; nat > > involved or not ? > > The current service I am access is a router located on one of the > external networks. > > > It seems odd to me if the service is hosted on the gateway the nw rule is > > hit as the local table lookup has pref 1 while the NW policy rules start > > from 20000 > > The route that needs to be hit is contained in main. Here is a more > detailed description of what happens. > > - External router has IP 192.168.0.1 and netmask 255.255.255.0. > - When I try to access this router, outgoing traffic is routed > correctly as it does not match any source rules and hit the network > rule in the main table (192.168.0.0/24 dev X src Y). > - When the reply comes, problem occurs. Since the network rule is > checked before the main table, we get a match on the "from > 192.168.0.0/24"-rule and packet is routed back out on the > 192.168.0.0/24 interface. The correct route (i.e., the route for my > local network) is in the main table. > Ah ok I see the issue; traffic coming from behind the gateway and targeted to a direct connected device on the wan is impacted. > > I have a question about this patch. In what scenario is it needed? Or > rather, will you ever use source based routing and have a default route in the main table? As far as I remember, these rules are only Indeed we're using source based routing in combination with a default route in the main routing table; even the specific routing table(s) can contain a default route Based on the addr rule the traffic is guided to a specific routing table so it leaves on the correct interface Hans > added when you have specified an ip4/ip6table. Or do you have one interface without an ipXtable value? > > -Kristian >
On Wed, Sep 23, 2015 at 1:07 PM, Hans Dedecker <dedeckeh@gmail.com> wrote: > Indeed we're using source based routing in combination with a default route > in the main routing table; even the specific routing table(s) can contain a > default route > Based on the addr rule the traffic is guided to a specific routing table so > it leaves on the correct interface Thanks for letting me know. If you add the lo-rules, then do you do not need the default route in main table. Or does this break something else? Note that I am talking about v4, I dont currently have a v6-network to test with :( -Kristian
On Wed, Sep 23, 2015 at 1:23 PM, Kristian Evensen <kristian.evensen@gmail.com> wrote: > On Wed, Sep 23, 2015 at 1:07 PM, Hans Dedecker <dedeckeh@gmail.com> wrote: >> Indeed we're using source based routing in combination with a default route >> in the main routing table; even the specific routing table(s) can contain a >> default route >> Based on the addr rule the traffic is guided to a specific routing table so >> it leaves on the correct interface I should point out that I don't know what the "correct" behavior and how (if) this should be solved. But these patches do break earlier working use-cases, so I am not sure what the OpenWRT-policy on this is. -Kristian
On Wed, Sep 23, 2015 at 11:44 PM, Kristian Evensen < kristian.evensen@gmail.com> wrote: > On Wed, Sep 23, 2015 at 1:23 PM, Kristian Evensen > <kristian.evensen@gmail.com> wrote: > > On Wed, Sep 23, 2015 at 1:07 PM, Hans Dedecker <dedeckeh@gmail.com> > wrote: > >> Indeed we're using source based routing in combination with a default > route > >> in the main routing table; even the specific routing table(s) can > contain a > >> default route > >> Based on the addr rule the traffic is guided to a specific routing > table so > >> it leaves on the correct interface > > I should point out that I don't know what the "correct" behavior and > how (if) this should be solved. But these patches do break earlier > working use-cases, so I am not sure what the OpenWRT-policy on this > is. > Intention of the patches was to support more scenarios like a default route in the main table. As the patches currently break some other scenarios it will need some further tweaking. The main issue is the nw rule; therefore I would like to understand which scenario the nw rule is covering before just reverting to the "old" nw rule implementation. If no route is hit in the main routing table the traffic will also be returned on the wan interface in case of the "old" nw rule implementation; so i'm wondering if this rule is ever hit in a scenario The iif lo rule stuff was originally added to fix a kernel issue; but since it's used in other scenarios they can be re-added again after the main table lookup . Meanwhile I will do some further tweaking and testing with the different scenarios in mind. Hans > > -Kristian >
diff --git a/iprule.h b/iprule.h index b4b124c..e1ac84b 100644 --- a/iprule.h +++ b/iprule.h @@ -17,8 +17,8 @@ #include "interface-ip.h" -#define IPRULE_PRIORITY_ADDR 80000 -#define IPRULE_PRIORITY_NW 90000 +#define IPRULE_PRIORITY_ADDR 10000 +#define IPRULE_PRIORITY_NW 20000 #define IPRULE_PRIORITY_REJECT 4200000000 enum iprule_flags {
Specific IP address and network rules are now checked before the main table lookup as the main table often holds a default route. As a result the IP address and network rules pointing to s specific routing table will not be checked anymore; by reversing the order the specific routing tables are checked first if the ip rule matches. Signed-off-by: Hans Dedecker <dedeckeh@gmail.com> --- iprule.h | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-)