Port 65000 was your spec. That is why I came up with a rule for it. If you come up with a spec I can try and come up with a rule/

Use -I and not -A for the rules which you want balanced. Custom rules get applied after the other rules and you must get the RETURN rules applied at the top of the MULTIWAN_MARK chain.

You have a couple of (very) dodgy rules which are your tweak rules. If you give the IP address in the form IP1/IP2, IP2 is a network mask and you are not specifying a range! Your rules there won't work.

As an idea, you could segment your network differently. If you change your DHCP scope to start at 192.168.2.128, you could apply your rules to 192.168.1.128/25. Then for any IP address you don't want to have your MultiWAN rules, give them a static IP address below that, or a permanent static lease below that (although getting it to apply to an address which already has a lease is a PITA - you need to stop the DHCP server (dnsmasq) and only then edit /var/lib/dnsmasq/dnsmasq.leases. You also need to fix /etc/ethers (which is the same as the static leases in the webconfig) and then restart the DHCP server. Unfortunately when you stop dnsmasq, DNS lookups will fail so you need to be fairly quick with your editing).

Instead of Deluge, can you use Transmission running on ClearOS? If it is running on ClearOS, I don't think any of the destination port or source IP rules will apply.

Thank you Nick,

I have edit some rules again.

I only get this to work in this order.

Here are the screenshots:








About:

iptables -I MULTIWAN_MARK -t mangle -s 192.168.1.2 -p tcp --dport 65000 -j RETURN
iptables -I MULTIWAN_MARK -t mangle -s 192.168.1.2 -p udp --dport 65000 -j RETURN

or

iptables -A MULTIWAN_MARK -t mangle -s 192.168.1.2 -p tcp --dport 65000 -j RETURN
iptables -A MULTIWAN_MARK -t mangle -s 192.168.1.2 -p udp --dport 65000 -j RETURN

This doesn't work becouse Deluge is not using port 65000 for incomming download traffic.
It uses a lot random ports, I looked up a small range of ports that are used for incoming traffic and linked them to a specific WAN connection.

I am really not sure here. What rules have you applied. I think you currently have "192.168.1.0/24 via enp4s0". No other rules will be working as this rule fires first. You also have 192.168.1.0/24 to tcp/udp 51100:51200 via enp4s0. This will never do anything as it hits the previous rule first. The most it can do is repeat the action. Same for the following rule to tcp:563.

To be honest I don't know in this case how the firewall operates. I don't know if it hits something in MULTIWAN_MARK then goes to the corresponding rule MULTIWAN_enp4/5s0 what happens after that. It may go to the next MULTIWAN_MARK for further processing or it may exit the chain. If you say 192.168.1.217 correctly goes via enp5s0 then it seems like it looks like it still goes through all the MULTIWAN_MARK rules. Please can you confirm what you are expecting (perhaps with a screen dump of the rules in the webconfig)

Again, not really knowing multiwan that well, I suspect that what you need to get load balancing is to stop the packets stepping through the MULTIWAN_MARK chain. Try a rule at the command line like:

iptables -I MULTIWAN_MARK -t mangle -s 192.168.1.2 -p tcp --dport 65000 -j RETURN

iptables -I MULTIWAN_MARK -t mangle -s 192.168.1.2 -p udp --dport 65000 -j RETURN

If these have the desired effect, to make them permanent, put them in the Custom Firewall but change "iptables" to "$IPTABLES".

Thank you it works in this order, I think it was true that it has to do with the alphabetical order:

My ip table now:

Chain MULTIWAN_MARK (1 references)

 pkts bytes target     prot opt in     out     source               destination

  104 25085 MULTIWAN_enp4s0  all  --  *      *       192.168.1.0/24       0.0.0.0/0

    0     0 MULTIWAN_enp4s0  tcp  --  *      *       192.168.1.0/24       0.0.0.0/0            tcp dpts:51100:51200

    0     0 MULTIWAN_enp4s0  udp  --  *      *       192.168.1.0/24       0.0.0.0/0            udp dpts:51100:51200

    0     0 MULTIWAN_enp4s0  tcp  --  *      *       192.168.1.0/24       0.0.0.0/0            tcp dpt:563

    0     0 MULTIWAN_enp5s0  tcp  --  *      *       192.168.1.0/24       0.0.0.0/0            tcp dpt:9119

    0     0 MULTIWAN_enp5s0  all  --  *      *       192.168.1.217        0.0.0.0/0

I only have one problem now, port 65000 need to be load balanced on both WAN connections enp4s0 and enp5s0 (or all) on computer ip 192.168.1.2.
is this possible and would you be so kind, to write this ipconfig code for me for the custom firewall.

Whole

iptables -nvL -t mangle

Chain PREROUTING (policy ACCEPT 5369K packets, 14G bytes)

 pkts bytes target     prot opt in     out     source               destination

5369K   14G CONNMARK   all  --  *      *       0.0.0.0/0            0.0.0.0/0            CONNMARK restore

16531 3409K MULTIWAN_MARK  all  --  enp1s0 *       0.0.0.0/0            0.0.0.0/0            state NEW



Chain INPUT (policy ACCEPT 19056 packets, 4927K bytes)

 pkts bytes target     prot opt in     out     source               destination



Chain FORWARD (policy ACCEPT 5348K packets, 14G bytes)

 pkts bytes target     prot opt in     out     source               destination

5347K   14G CONNMARK   all  --  *      *       0.0.0.0/0            0.0.0.0/0            CONNMARK restore

    0     0 TCPMSS     tcp  --  *      ppp+    0.0.0.0/0            0.0.0.0/0            tcp flags:0x06/0x02 TCPMSS clamp to PMTU

    0     0 MULTIWAN_enp3s0  all  --  enp3s0 *       0.0.0.0/0            0.0.0.0/0

2804K   12G MULTIWAN_enp4s0  all  --  enp4s0 *       0.0.0.0/0            0.0.0.0/0

26624   53M MULTIWAN_enp5s0  all  --  enp5s0 *       0.0.0.0/0            0.0.0.0/0



Chain OUTPUT (policy ACCEPT 10820 packets, 5159K bytes)

 pkts bytes target     prot opt in     out     source               destination



Chain POSTROUTING (policy ACCEPT 5358K packets, 14G bytes)

 pkts bytes target     prot opt in     out     source               destination

5358K   14G CONNMARK   all  --  *      *       0.0.0.0/0            0.0.0.0/0            CONNMARK restore

   75  2653 MULTIWAN_enp3s0  all  --  *      enp3s0  0.0.0.0/0            0.0.0.0/0

2503K 1875M MULTIWAN_enp4s0  all  --  *      enp4s0  0.0.0.0/0            0.0.0.0/0

14148 1037K MULTIWAN_enp5s0  all  --  *      enp5s0  0.0.0.0/0            0.0.0.0/0



Chain MULTIWAN_MARK (1 references)

 pkts bytes target     prot opt in     out     source               destination

16529 3408K MULTIWAN_enp4s0  all  --  *      *       192.168.1.0/24       0.0.0.0/0

   27  1404 MULTIWAN_enp4s0  tcp  --  *      *       192.168.1.0/24       0.0.0.0/0            tcp dpts:51100:51200

    1    48 MULTIWAN_enp4s0  udp  --  *      *       192.168.1.0/24       0.0.0.0/0            udp dpts:51100:51200

    0     0 MULTIWAN_enp4s0  tcp  --  *      *       192.168.1.0/24       0.0.0.0/0            tcp dpt:563

    0     0 MULTIWAN_enp5s0  tcp  --  *      *       192.168.1.0/24       0.0.0.0/0            tcp dpt:9119

  157 10319 MULTIWAN_enp5s0  all  --  *      *       192.168.1.217        0.0.0.0/0



Chain MULTIWAN_enp3s0 (2 references)

 pkts bytes target     prot opt in     out     source               destination

   75  2653 MARK       all  --  *      *       0.0.0.0/0            0.0.0.0/0            MARK xset 0x10000000/0xf0000000

   75  2653 CONNMARK   all  --  *      *       0.0.0.0/0            0.0.0.0/0            CONNMARK save



Chain MULTIWAN_enp4s0 (6 references)

 pkts bytes target     prot opt in     out     source               destination

5324K   14G MARK       all  --  *      *       0.0.0.0/0            0.0.0.0/0            MARK xset 0x20000000/0xf0000000

5324K   14G CONNMARK   all  --  *      *       0.0.0.0/0            0.0.0.0/0            CONNMARK save



Chain MULTIWAN_enp5s0 (4 references)

 pkts bytes target     prot opt in     out     source               destination

40929   54M MARK       all  --  *      *       0.0.0.0/0            0.0.0.0/0            MARK xset 0x30000000/0xf0000000

40929   54M CONNMARK   all  --  *      *       0.0.0.0/0            0.0.0.0/0            CONNMARK save

There may be a trick to make this work. You have given both rules a "nickname". Can you try changing the nickname of one so it reverses the order of them alphanumerically? I think the rules get added to iptables in nickname order. Otherwise, if you don't mind a bit of general traffic escaping from your port based rule interface, don't set a source rule and just set the priority very high for your general interface.

If the first trick and second method do not work, you will need a custom firewall rule to force the port based rule to take precedence. For that, Id need to see the output of:

iptables -nvL -t mangle