I have an internal LAN configuration that's slightly more complicated than either a simple device/ip/netmask with no gateway or a device/ip/netmask/gateway for all traffic. Specifically, the LAN is divided into part that requires no gateway and a part that does require a gateway because the latter is on a separate subnet and goes through a second router device to get there. Net-ISP-Balance
is incorrectly concluding that all traffic has to go through that gateway and that results in it computing and using ip/netmask combinations that are broken.
On the LAN, the directly accessible segment is on 192.168.11.x
. The secondary subnet segment is on 192.168.10.x
. The internet gateway device sitting between the ISP nodes and the main LAN is IP 192.168.11.20
. And the secondary subnet router on the internal LAN is at 192.168.11.23
. I have things configured such that the LAN itself is configured as 192.168.10.0/23
, which includes both subnets. And there is a static gateway route for 192.168.10.0/24
to that 192.168.11.23
device for that subnet. This allows all computers on either subnet to see and communicate with all devices on either subnet as if they were all on the same subnet, making the secondary gateway transparent (this is all needed because the secondary subnet is connected via a WiFi access point instead of a wired Ethernet cable and so can't just be bridged, as only traffic bound for the WiFi negotiating client gets correctly routed there -- i.e. the other gateway itself).
Dumping the route tables for when things are correctly configured and working:
$ ip route show all
default via 10.161.170.65 dev enp3s0 proto static metric 101
169.254.0.0/16 dev enp3s0 scope link metric 1000
10.161.170.64/26 dev enp3s0 proto kernel scope link src 10.161.170.112 metric 101
192.168.10.0/24 via 192.168.11.23 dev enp1s0 proto static metric 102
192.168.10.0/23 dev enp1s0 proto kernel scope link src 192.168.11.20 metric 102
$ route -n
Kernel IP routing table
Destination Gateway Genmask Flags Metric Ref Use Iface
0.0.0.0 10.161.170.65 0.0.0.0 UG 101 0 0 enp3s0
169.254.0.0 0.0.0.0 255.255.0.0 U 1000 0 0 enp3s0
10.161.170.64 0.0.0.0 255.255.255.192 U 101 0 0 enp3s0
192.168.10.0 192.168.11.23 255.255.255.0 UG 102 0 0 enp1s0
192.168.10.0 0.0.0.0 255.255.254.0 U 102 0 0 enp1s0
enp1s0
is the LAN. enp3s0
is one of the ISP WAN connections. The other ISP WAN is currently down in this output, as I am mainly trying to sort out the routing on the LAN side.
As you can see in that last entry, anything for 192.168.10.0/23
(i.e. both subnets) goes to interface enp1s0
. But things for 192.168.10.0/24
(i.e. the secondary subnet) goes to the gateway at 192.168.11.23
. But that is ONLY traffic bound to that secondary subnet. Net-ISP-Balance
is incorrectly deciding that all traffic on enp1s0
should go to gateway 192.168.11.23
. Here's the commands it's trying if you run it in debug mode:
ip route add 192.168.10.0/24 dev enp1s0 src 192.168.11.20
ip route add 10.161.170.64/26 dev enp3s0 src 10.161.170.112
ip route add default via 10.161.170.65 dev enp3s0
ip route flush table 1
ip route add table 1 default dev enp3s0 via 10.161.170.65
ip route add table 1 192.168.10.0/24 dev enp1s0 src 192.168.11.20
ip route add table 1 10.161.170.64/26 dev enp3s0 src 10.161.170.112
ip rule add from 10.161.170.112 table 1
ip rule add oif enp3s0 table 1
ip rule add fwmark 1 table 1
As you can see, the netmask ranges it is computing are incorrect and not consistent even with the IP address of the interface. That first line should be: ip route add 192.168.10.0/23 dev enp1s0 src 192.168.11.20
, using the 255.255.254.0
netmask instead of 255.255.255.0
, as the IP 192.168.11.20
is otherwise not consistent with the mask it's trying to use.
I've been putting some debug print statements in the script to get a better idea of what it's seeing and to figure out what is happening. Here's the output through the stages of interface_info
:
Find virtual interfaces:
vdev: lo block: 127.0.0.0/8 addr: 127.0.0.1
vdev: enp1s0 block: 192.168.10.0/23 addr: 192.168.11.20
vdev: enp3s0 block: 10.161.170.64/26 addr: 10.161.170.112
Find existing routes:
vdev: enp3s0 nets: (default) gws: 10.161.170.65
vdev: enp1s0 nets: 192.168.10.0/24 gws: 192.168.11.23
Interfaces:
dev: lo
vdev: lo
running: 1
gw: 127.0.0.1
net: 127.0.0.0/8
ip: 127.0.0.1
dev: enp1s0
vdev: enp1s0
running: 1
gw: 192.168.11.23
net: 192.168.10.0/24
ip: 192.168.11.20
dev: enp3s0
vdev: enp3s0
running: 1
gw: 10.161.170.65
net: 10.161.170.64/26
ip: 10.161.170.112
The problem seems to be that it's confused by the extra static route that routes the 192.168.10.0/24
traffic to the extra 192.168.11.23
gateway. It found the correct block when it was enumerating the virtual interfaces, but then incorrectly picked the netmask and gateway of the static route when computing the overall interface, as that net for enp1s0
should be 192.168.10.0/23
instead of /24
and there shouldn't be a gateway (or the gateway should be showing as 192.168.11.20
, or the interface itself).
At the moment, I haven't found the best solution for this. It seems it needs to clue in on the static
keyword in the route table and perhaps compare the netmasks of each gateway on each interface to the IP for the interface itself. But that's not totally trivial in the current code.
Since this is somewhat fixed network topology for my setup and isn't dynamically changing, my current workaround is to just manually set up these LAN routes and interface configurations rather than having it automagically figure it out. But it is a shortcoming that needs to be fixed in Net-ISP-Balance
, since as it is it's broken and results in a nonworking configuration -- hence my filing this issue.