Hi Lynn
If you find out the IP range of the site you wish to forward down one WAN then maybe a source based route is the one for you?
http://www.clearfoundation.com/docs/user_guide/clearos_enterprise_5.1/multi-wan

Thanks for the pointer. I'm sure I could isolate the IP range. However, I couldn't find any info on the topic. I don't think it's documented yet:

http://www.clearfoundation.com/docs/image/multiwan_sbr.png

Is there some other documentation I'm missing?

I'm also interested in this topic and I couldn't find any info here www.clearfoundation.com/docs/user_guide/...rprise_5.1/multi-wan There are no screenshots

I'll chime in with a 'me too'

I think that source based routing will not help in this case because the problem is with the WAN destination rather than a single LAN source.

Seems that youtube videos embedded in other pages are particularly susceptible to breaking when using multi-WAN

Regards,
Jeff

I really confuse to implemented like this :

I have 2 lines internet joined with multiWAN and i want to control traffic, if clients open www.yahoo.com it always flow through line 1, then if they want to access www.google.com, it always use line 2

------- line 1 (yahoo.com)
|
clients(192.168.1.0/24)-----
|
-------- line2 (google.com)

1. first get the yahoo/google domains address (something like 209.191.64.0 - 209.191.127.255 for yahoo)
2. add to rc.local (etc/rc.d/rc.local ot rc.local.firewall) two line (one per rule):
route add -net 209.191.65.0 gw ip-wan1 netmask 255.255.128.0
route add -net 98.136.0.0 gw ip-wan2 netmask 255.255.0.0
3. reboot/ run rc.local

Note that from now on all address from yahoo/google domains (like *.yahoo.com/*.google.com) will be routed to corresponding WAN.

hope this help
regards

How to write the command if destination ip more than one ip.Like game server that has ip range from 203.120.11.12 to 203.120.11.56?

Anyway,can we do this setting via webconfig? just for make it easy :P

I'm also interested in a solution to this topic.

What tvriasi proposed seems more like a "workaround" to me then a real solution.

Why?

Because it's not integrated to syswatch and the whole MultiWan system. Supose the following scenario:

I have two uplinks, ProviderA and ProviderB, and I want to acces external siteC, always from a single provider, na matter which. So I decide to add the following line to rc.local:

route add -net siteC gw ip-ProviderA netmask 255.255.255.0

So far, so good. All traffic to siteC will flow through ProviderA.

Now, supose that my link to providerA goes down. syswatch will automagically switch default route to providerB, however siteC will be unaccessible since I have a static route to siteC through providerA. :angry:

The real solution is to implement destination based routing integrated to the system, so that when providerA goes down ALL traffic will flow through providerB. When providerA comes back, traffic to siteC will again be routed through providerA, and ALL other traffic will be loadballanced again.

Hope that a feature like this will be included in future versions.

rgrds,
Bráulio Gergull

I just wanted to resurrect this topic since it's been about three months since the last post and to throw in a "me too!" Sure, I can manually edit routes, but I think there are a lot of people out there, myself included, that would really appreciate if Clear could write some kind of gui for multiwan destination based routing.

I second the motions of the previous speakers. We REALLY need destination based routing for Multiwan, in the robust fashion as outlined above.

I'm an ardent supporter an longtime user of Clark / Clear, but the lack of routing commands in a router always struck me as strange.

I once had the ear of a developer (I pay) and he said it's harder to implement than it may look at the surface. That's all well and good, but we need it.

We REALLY need destination based routing for Multiwan, in the robust fashion as outlined above.

Hi all,

that would really appreciate if Clear could write some kind of gui for multiwan destination based routing.

I want to get away from the old caretaker role that we used to have :-) ANYONE can contribute this feature, not just the ClearCenter team or ClearFoundation developers. Anyone.

Moving on...

Here's the crux of the problem. The routing decision is already made by the time a destination route can be added in the same manner that is done with source-based routes. That's why source-based routes exist, but not destination routes. Trust me, if it were possible to do without re-writing the entire firewall, it would have been in ClearOS a loooong time ago.

I'm an ardent supporter an longtime user of Clark / Clear, but the lack of routing commands in a router always struck me as strange.

You can certainly add routes! What causes grief is that multi-WAN is more complex when it comes to routing. It's not that bad really, it's more about understanding what's going on under the hood and making it a habit never to use the old school route command anymore. I still catch myself using it... old habits. Fortunately, there's a technical document on multi-WAN routing here .

You can certainly add static routes as a workaround to destination-based routes. If you add them using the standard "Red Hat" way as described in the ClearCenter docs, then you might not run into the problem described by gergull.

Ok so i introduced a friend to ClearOS (which I don't really use anymore as I use zeroshell for VPN bonding and some other more complicated things that aren't easily setup on clearOS in a web-interface. The problem is that zeroshell is pretty complex for beginners especially if you want to turn it into a full fleged system (instead of just a router) which is one big complaint I have about zeroshell.

Anyway my friend wanted to route over a connection depending on destination IP for gaming and to prevent quakelive from bitching about his IP addresses changing on the web-interface. I actually though of a solution for a little bit (intiially was just gonna have him manually run the iptables command) but instead I realized I could just look at the source IPs and if it wasnt your LAN IP (since clearOS does accept an IP that is not on your LAN subnet (but probably shouldn't?) that I could just use the web-interface entries and change the iptables rules to use them as destination instead.


I did a quick test of this on my dad's ClearOS box. Charter is weighted 200 vs uverse weighted at 1 due to the speed diference on the connections. When I added a source IP of 208.97.143.21 to go through uverse and source ip 208.97.140.21 to go through charter they worked correctly:


myth ~ # traceroute -I 208.97.143.21
traceroute to eth3.houkouonchi.jp (208.97.143.21), 30 hops max, 46 byte packets
1 1.1.1.1 (1.1.1.1) 0.167 ms 0.140 ms 0.108 ms
2 1.2.2.1 (1.2.2.1) 0.929 ms 0.719 ms 0.999 ms
3 99-10-164-2.lightspeed.irvnca.sbcglobal.net (99.10.164.2) 20.940 ms 20.318 ms 20.460 ms
4 * * *
5 * * *
6 151.164.102.70 (151.164.102.70) 22.991 ms 48.562 ms 22.260 ms
7 151.164.102.98 (151.164.102.98) 100.503 ms 60.034 ms 49.532 ms
8 xe-0-2-0-4.r04.lsanca03.us.bb.gin.ntt.net (129.250.9.169) 22.996 ms xe-0-2-0-5.r04.lsanca03.us.bb.gin.ntt.net (129.250.9.173) 22.872 ms 22.938 ms
9 xe-0-6-0-3.r04.lsanca03.us.ce.gin.ntt.net (198.172.90.70) 22.711 ms 22.905 ms 23.046 ms
10 ip-66-33-201-214.dreamhost.com (66.33.201.214) 23.260 ms 23.210 ms 42.669 ms
11 eth3.houkouonchi.jp (208.97.143.21) 22.922 ms 22.996 ms 23.226 ms

myth ~ # traceroute -I 208.97.140.21
traceroute to box.houkouonchi.jp (208.97.140.21), 30 hops max, 46 byte packets
1 1.1.1.1 (1.1.1.1) 0.585 ms 0.151 ms 0.107 ms
2 10.92.36.1 (10.92.36.1) 8.156 ms 7.290 ms 9.288 ms
3 acr02rvsdca-gbe-2-3.rvsd.ca.charter.com (96.34.100.202) 6.902 ms 7.029 ms 9.480 ms
4 96-34-98-58.static.unas.ca.charter.com (96.34.98.58) 13.055 ms 8.432 ms 11.624 ms
5 bbr01rvsdca-tge-0-1-0-6.rvsd.ca.charter.com (96.34.2.30) 9.251 ms 10.674 ms 8.048 ms
6 prr01lsanca-2-3.lsan.ca.charter.com (96.34.3.88) 11.159 ms 12.038 ms 12.077 ms
7 96-34-156-6.static.unas.mo.charter.com (96.34.156.6) 11.168 ms 11.524 ms 10.900 ms
8 pos-2-0-0-0-cr01.losangeles.ca.ibone.comcast.net (68.86.86.57) 10.404 ms 11.719 ms 10.579 ms
9 as26347.losangeles.ca.ibone.comcast.net (75.149.228.206) 10.450 ms 12.463 ms 10.684 ms
10 ip-66-33-201-114.dreamhost.com (66.33.201.114) 17.049 ms * 193.286 ms
11 box.houkouonchi.jp (208.97.140.21) 10.577 ms 18.147 ms 9.954 ms


Basically i just added this to /etc/rc.d/rc.firewall.local

#Make non LAN source IPs destination IPs instead

lan=`cat /etc/firewall | grep LANIF | cut -d'"' -f2`

natsub=`ifconfig $lan | grep inet\ addr | cut -d':' -f2 | cut -d'.' -f1-3`



for ip in `iptables -t mangle -v -n -L MULTIWAN_MARK | grep -v Chain | grep -v source | awk '{print $8}' | grep -v $natsub.`

        do

        int=`iptables -t mangle -v -n -L MULTIWAN_MARK | grep $ip | awk '{print $3}'`

        iptables -t mangle -D MULTIWAN_MARK -p all -s $ip -j $int

        iptables -t mangle -A MULTIWAN_MARK -p all -d $ip -j $int

done

#Make non LAN source IPs destination IPs instead

Basically all this does is look at source IPs not on your subnet. The grep command that is 192.168.1. should be changed to whatever your LAN subnet is. This is what my friend used but in my case it was 1.1.1. (as I like that scheme and honestly can't give a crap if i can't access 1.1.1.0/24 now that its finally allocated after 10 years of not being allocated.


Keep in mind this is basically a dirty HACK! It should allow destination ports and source IPs where you properly use LAN computers for when you want to force a computer on your network to use the specified interface but might break on newer versions of clearOS and isn't gauranteed by me. It seemed to work fine when I tested it though =)

I have some other additions to this file for like looping NAT on the box so when I access externalIP:forwarded port on a nother computer on the LAN I am able to see the content (like the outside does) and it routes through the router box (on a moderate system i could still get a couple hundred megabits doing this) as well as doing NAT over openVPN connections for routing machines through VPN that are on my NAT'd local network

Oh and just a quick add these rules (as with the normal rules on this page) only take affect for machines *behind* the clearOS box (not on the box itself). Likely static routes would be needed to take effect on the box as well.