In our example setup we have configured the following network:
As you can see there are 3 subnets:
- 10.192.64.0/28 – the local DMZ between the router and adsl modems. This network in our case was also physical seperate but it doesn’t have to be. It makes a lot of sense security wise though.
- 172.27.1.0/24 – the private network for computer data.
- 10.27.1.0/24 – the private network for the voice data.
Following on from the brief discussion back in What you need. Subnets 2 and 3 share the same physical network and the same physical device (eth1). The rules that govern which routing table is used to route the packet use the packets source address (i.e. Source Based Routing) as the selector. The source for each rule can either be a subnet or a single host address.
In my opinion it is easier to maintain a set of dhcp hosts that are allowed to be assigned an addresses in subnet 3′s address pool; and subsequently have one RPDB rule for subnet 3. As opposed to having M (where M is the number of network clients that should use the routing table) RPDB rules and somehow statically assigning addresses to those M clients (e.g. true static ip or fixed-address with dhcp).
If you only have one device that will use the alternate routing table then you can save yourself some hassles setting up dhcp. Note: If you choose to have seperate subnets you will need to use the shared-network option in your dhcpd.conf file. Assuming you are using dhcp.
Lets examine the example scripts you downloaded earlier.
For the public interface eth0:
- From the diagram above you can see the two adsl modems have IPs 10.192.64.2 (primary) and 10.192.64.3 (secondary). For completeness we add a route to this subnet, from the router IP 10.192.64.1, into the MyTable routing table.
ip route add 10.192.64.0/28 dev eth0 src 10.192.64.1 table MyTable
This route must be created and removed when eth0 is activated / deactivated because it has dev eth0.
For the private interface eth1:
- Seen as though eth1 is shared between both subnets 2 and 3 it needs to be assigned an address in both subnets.
ip addr add 10.27.1.5/24 brd 10.27.1.255 dev eth1
Note: This new IP address will be the default gateway of subnet 3. We chose to use the same last octet in both subnets (.5); this makes it easy to remember. - Add rules to the RPDB so that traffic meant for MyTable actually goes through MyTable.
ip rule add prio 200 from 10.27.1.0/24 lookup MyTable
ip rule add prio 201 from 10.192.64.3 lookup MyTable
Here rule one uses source addresses from 10.27.1.0/24, which is subnet 3; and on the other side of the router 10.192.64.3 as noted above is the secondary connection modem address. The prio(rity) values are arbitary but should not interfere with the main and local rules. You can view the rules by running: ip rule show - Next we create a copy of the normal routing table in MyTable:
ip route add 10.27.1.0/24 dev eth1 src 10.27.1.5 table MyTable
ip route add 127.0.0.0/8 dev lo table MyTable
ip route add default via 10.192.64.3 src 10.192.64.1 table MyTable
See that the default route goes via 10.192.64.3 this is the reverse of the rule added in #2 above. Technically access to localhost is not neccessary but is here for completeness. - This part is a little tricky and entirely optional:
ip route add 172.27.1.0/24 dev eth1 src 172.27.1.5 table MyTable
ip route add 10.27.1.0/24 dev eth1 src 10.27.1.5 table main
This bridges the two subnets, allowing the clients in each subnet to communicate with each other. If you don’t need the clients to communicate then you don’t need to do this. In our case to access the web based configuration interface or perform firmware upgrades we needed to be able to access the voip clients from the computers.
The final command:
The changes made in the script do not automatically take effect. You need to instruct the kernel to reload the rules (i.e. flush the cache):
ip route flush cache
If you examine the if-down script you will see these commands are literally reversed as such they are not explained.
<- Networking | Final Notes ->