Server Fault is a question and answer site for system and network administrators. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

I am trying to configure a router which provides Internet to a couple hundred users. This router has 4 basic cable uplinks at its disposition, which all use DHCP and have a capacity of around 10/1 Mbps.

The router has 3 interfaces :

  • eth0 connected to admin network, 192.168.A.0/24 (can be ignored)
  • eth1 connected to users network, 192.168.B.0/23
  • eth2 connected to a VLAN switch, with the modems on 4 different VLANs.

ip route, ip rule and iptables details can be found here :

VLAN numbers are 24 through 27, and the corresponding routing tables have the same numbers. Each of these routing tables contains link-level entries for eth0, eth1, and eth2.X, as well as the default route given by the DHCP server. Note that it is possible that 2 of the modems end up on the same subnet...

I use CONNMARK and ip rule to mark connections and redirect them to modem-specific routing tables. I also have a dhclient-hook which takes care of updating these secondary routing tables whenever the DHCP lease is updated.

Default iptables policy is DROP for INPUT and FORWARD, and ACCEPT for OUTPUT. Note that the ip rule section redirects fwmarks 3 & 4 back to modems 1 & 2, but this is temporary as the other 2 modems are still passing the traffic from the users (we can't totally disconnect them...)

Now with all of that said, this solution kinda works, but exhibits about 50% packet loss, whatever the chosen uplink :-/ Could someone be so kind as to tell me what it is that I'm doing wrong? I have been poking at this problem for several hours now and it is getting extremely frustrating...

Thanks in advance, - Thomas

share|improve this question
up vote 0 down vote accepted

I think that I have found the problem : CONNMARK. In mangle-PREROUTING, it seems that the --restore-mark only sets the mark for the next table, so the subsequent rules match --mark=0 and set a new mark for each packet.

The solution would be to only mark packets matching --state NEW. However we also decided that clients should have consistent IPs when accessing websites, otherwise some applications, notably e-banking, fail.

So finally the marking was done on an IP basis, with our source pool split across multiple /25 subnets.



share|improve this answer

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.