[mythtv-users] OT: default routes

Wed Sep 23 09:32:09 UTC 2015

Hika van den Hoven <hikavdh at gmail.com> wrote:

>> (Assuming you're using GNU/Linux for your router) I've not done
>> this myself natively with iptables, I usually use Shorewall for my firewall setups.
> 
> OK, sounds useful. My router is running fli4l, a dressed down standard
> linux. The route command is not there. I have to use 'ip route'

The "ip" command is the current method (and has been for some time) - it rolls up a few separate but related tools (eg route & ifconfig) into one.

> and it
> runs iptables. One problem is that it has a configuration shell in
> which I cannot do anything like this. I even, if I want to change the
> default route, have to do it after booting on the prompt. It goes
> automatically to the pppoe device and the new connection is a normal
> ip connection to the modem/router. But I can create a script to run
> after boot, or to switch between the routes.
> 
> So is this conditional routing done with ip route? (I haven't seen any
> syntax) or through iptables?

As I say, I've only done it with Shorewall which hides all that low level detail. I suspect it's a combination of using "ip route" to setup the routing tables, and iptables to mark packets.

I can show you some bits from a live system (with stuff sanitised). Unfortunately it's somewhat more complicated than you need because Tom Eastep had to write a generic system that would work for many different use cases. We have a FTTC line we use here for our office traffic, but the gateway is also connected to our hosting network which we can directly access and also use if the FTTC line is down (requires manual intervention).

Actually, if you want, you can probably skip some the rest of this, because since I wrote it, I went looking for info on writing the routing rules and came across this :
http://blog.scottlowe.org/2013/05/29/a-quick-introduction-to-linux-policy-routing/

see also http://lartc.org/howto/lartc.rpdb.html and the following page or two. In fact, the whole howto is worth a skim - you might be amazed what's possible.

On checking the syntax for ip rule (ip rule help), I find you can't be all that creative in the matches - so you'll probably need to use fwmarks as below.

> # shorewall show routing
> Shorewall 4.5.5.3 Routing at fw - Wed Sep 23 08:37:07 UTC 2015
> 
> 
> Routing Rules
> 
> 0:	from all lookup local 
> 999:	from all lookup main 
> 1000:	from 192.168.1.0/24 lookup fttc 
> 10000:	from all fwmark 0x1/0xff lookup fibre 
> 10001:	from all fwmark 0x2/0xff lookup fttc 
> 20000:	from a.b.c.45 lookup fibre 
> 20000:	from x.y.z.255 lookup fttc 
> 32765:	from all lookup balance 
> 32766:	from all lookup main 
> 32767:	from all lookup default 
> 
> Table balance:
> 
> default nexthop via a.b.c.254 dev eth0 weight 1 nexthop dev ppp10 weight 1
> 
> Table default:
> 
> 
> Table local:
> 
> local x.y.z.255 dev ppp10 proto kernel scope host src x.y.z.255
> local a.b.c.45 dev eth0 proto kernel scope host src a.b.c.45
> local 192.168.1.1 dev eth2 proto kernel scope host src 192.168.1.1
> local 127.0.0.1 dev lo proto kernel scope host src 127.0.0.1
> local 127.0.0.0/8 dev lo proto kernel scope host src 127.0.0.1
> broadcast a.b.c.255 dev eth0 proto kernel scope link src a.b.c.45
> broadcast a.b.c.0 dev eth0 proto kernel scope link src a.b.c.45
> broadcast 192.168.1.255 dev eth2 proto kernel scope link src 192.168.1.1
> broadcast 192.168.1.0 dev eth2 proto kernel scope link src 192.168.1.1
> broadcast 127.255.255.255 dev lo proto kernel scope link src 127.0.0.1
> broadcast 127.0.0.0 dev lo proto kernel scope link src 127.0.0.1
> 
> Table main:
> 
> nn.nn.nn.nn dev ppp10 proto kernel scope link src x.y.z.255 <- default GW from PPP
> a.b.c.254 dev eth0 scope link src a.b.c.45
> a.b.c.0/24 dev eth0 proto kernel scope link src a.b.c.45
> 192.168.1.0/24 dev eth2 proto kernel scope link src 192.168.1.1
> 
> Table fttc:
> 
> default dev ppp10 scope link
> 
> Table fibre:
> 
> a.b.c.254 dev eth0 scope link src a.b.c.45
> default via a.b.c.254 dev eth0 src a.b.c.45

For comparison, this is the ip route command to show one of the routing tables, so it should be fairly easy to see how to build up the routes required.

> # ip route list table fttc
> default dev ppp10  scope link 

What I'm not sure about is the very first bit of the Shorewall output - setting the list of routing rules. These break down as :
0:	from all lookup local
Local traffic - ie directly connected networks

999:	from all lookup main 
How to reach the gateways - seems to have some overlap with the local table

1000:	from 192.168.1.0/24 lookup fttc 
Here I have a Shorewall rule directing all traffic from the LAN via the FTTC line

10000:	from all fwmark 0x1/0xff lookup fibre 
10001:	from all fwmark 0x2/0xff lookup fttc 
Then lookup based on packet marks

20000:	from a.b.c.45 lookup fibre 
20000:	from x.y.z.255 lookup fttc 
Then route based on source address

32765:	from all lookup balance 
32766:	from all lookup main 
32767:	from all lookup default 
And if none of the earlier rules matched, then try balancing traffic, going via the main table, and if all else fails, use the default route.

In your case, I suspect you could simplify it somewhat, and just use packet marking to force certain traffic via one provider while shoving everything else via the default route.

I don't actually have any packet marking going on on this box, so my mangle table is fairly empty :
> # iptables -n -L -t mangle
> Chain PREROUTING (policy ACCEPT)
> target     prot opt source               destination         
> CONNMARK   all  --  0.0.0.0/0            0.0.0.0/0            connmark match ! 0x0/0xff CONNMARK restore mask 0xff
> routemark  all  --  0.0.0.0/0            0.0.0.0/0            mark match 0x0/0xff
> routemark  all  --  0.0.0.0/0            0.0.0.0/0            mark match 0x0/0xff
> tcpre      all  --  0.0.0.0/0            0.0.0.0/0           
> tcpre      all  --  0.0.0.0/0            0.0.0.0/0           
> tcpre      all  --  0.0.0.0/0            0.0.0.0/0            mark match 0x0/0xff
> 
> Chain INPUT (policy ACCEPT)
> target     prot opt source               destination         
> tcin       all  --  0.0.0.0/0            0.0.0.0/0           
> 
> Chain FORWARD (policy ACCEPT)
> target     prot opt source               destination         
> MARK       all  --  0.0.0.0/0            0.0.0.0/0            MARK and 0xffffff00
> tcfor      all  --  0.0.0.0/0            0.0.0.0/0           
> 
> Chain OUTPUT (policy ACCEPT)
> target     prot opt source               destination         
> CONNMARK   all  --  0.0.0.0/0            0.0.0.0/0            connmark match ! 0x0/0xff CONNMARK restore mask 0xff
> tcout      all  --  0.0.0.0/0            0.0.0.0/0            mark match 0x0/0xff
> 
> Chain POSTROUTING (policy ACCEPT)
> target     prot opt source               destination         
> tcpost     all  --  0.0.0.0/0            0.0.0.0/0           
> 
> Chain routemark (2 references)
> target     prot opt source               destination         
> MARK       all  --  0.0.0.0/0            0.0.0.0/0            MARK set 0x1
> MARK       all  --  0.0.0.0/0            0.0.0.0/0            MARK set 0x2
> CONNMARK   all  --  0.0.0.0/0            0.0.0.0/0            mark match ! 0x0/0xff CONNMARK save mask 0xff
> 
> Chain tcfor (1 references)
> target     prot opt source               destination         
> 
> Chain tcin (1 references)
> target     prot opt source               destination         
> 
> Chain tcout (1 references)
> target     prot opt source               destination         
> 
> Chain tcpost (1 references)
> target     prot opt source               destination         
> 
> Chain tcpre (3 references)
> target     prot opt source               destination         

As this is "somewhat past my comfort zone" I'm afraid it's about as helpful as I can be.
I think you'll want to be adding rules to the mangle table to mark certain types of traffic - eg GRE traffic going out via a specific port for the VPN tunnel. Some experimentation may be needed.