Aaron P. Martinez wrote:
On Tue, 2005-01-25 at 16:08, James Hammer wrote:
The tricky part is that it is not true load balancing. In the project description I was given, certain types of traffic were to go out a specific interface all the time. If that interface were to go down then that specific traffic should be switched over to the interface that is up. For example, we route all http traffic over the DSL line. If the DSL line goes down we route it over the T1. So the desired effect is mostly failover, not load balancing.
I setup failover using only the Julian Anastasov kernel patch, ip rules, and a firewall according to the outline in http://www.ssi.bg/~ja/nano.txt. No virtual devices were created. I just setup the routing tables and the Anastasov kernel patch handles the rest. I do use keepalived to detect when a route goes down. Keepalived can then run an external script to handle changes to the routing table.
The basic idea is to setup a separate routing table for each interface. In the firewall if traffic meets a certain criteria it is given a certain fwmark. Using this fwmark I then send the traffic out the appropriate interface using an ip rule. If traffic is not marked by the firewall then it reaches a default table which does load balance the traffic over the two interfaces.
Here is how the rules and routing are setup:
# ip route show table 201 default via $T1GATEWAY dev eth2 proto static src $T1IP prohibit default proto static metric 1
# ip route show table 202 default via $DSLGATEWAY dev eth1 proto static src $DSLIP prohibit default proto static metric 10
# ip route show table 222 default proto static nexthop via $T1GATEWAY dev eth2 weight 1 nexthop via $DSLGATEWAY dev eth1 weight 1
# ip rule show:
0: from all lookup local 50: from all lookup main 100: from all fwmark 0x2 lookup 202 101: from all fwmark 0x2 lookup 201 110: from all fwmark 0x3 lookup 201 111: from all fwmark 0x3 lookup 202 201: from $T1NETWORK lookup 201 202: from $DSLNETWORK lookup 202 222: from all lookup 222 32766: from all lookup main 32767: from all lookup default <snip>
I quote here from http://www.ssi.bg/~ja/nano.txt:
"Table local is used for the local loopback, table main has the network routes to the internal network and for the external interfaces, which only give access to our gateways. Tables 201 and 202 (which also might have the same priority), will provide a default route if the local source address is known (because they have to match NWE1 or NWE2). And table 222 will provide the multipath route. The tables with priority 32766 and 32767 will not be used."
In addition I am using the fwmark rules to send the specifically marked traffic out the given interface. The order of the rules is important. Let's say the T1 were to go down. Rule 110 would automatically be removed so that now traffic marked with fwmark 0x2 and 0x3 will go to table 202 which is the DSL. The kernel patch also makes it so that any traffic that hits table 222 will know that the T1 is down and will be sent over the DSL route.
Nothing is set to specifically use port 1025 in snats or otherwise (or any of the other ports it has changed to such as 1024 and 1026).and 1 internal interface. iproute2 and iptables are used to force the vpn traffic over the T1.
Here are pre and postrouting for the VPN.
# Mark traffic bound for T1 by default
$BIN -A PREROUTING -t mangle -p udp --dport 5000 -j MARK --set-mark 3
$BIN -t mangle -A OUTPUT -p udp --dport 5000 -d ! 192.168.1.0/24 -j MARK --set-mark 3
Then, depending on the state of the T1 the following is also set:
If T1 is up: $BIN -I POSTROUTING -t nat -p udp --dport 5000 -d ! 192.168.1.0/24 -j SNAT --to $T1_IP
If T1 is down: $BIN -I POSTROUTING -t nat -p udp --dport 5000 -d ! 192.168.1.0/24 -j SNAT --to $DSL_IP
Looking at the log file on the remote openvpn server I see the following:
Yes. They are the same. The only thing that changes is the port.
Have you thought about using a current version, even to the current
This is a good suggestion and I have switched it back. I had read in the man page that 'port' should handle both the local and remote ports but since the local port was changing I thought I would give it a try. It had no effect though.
I will mention that setting the 'float' option in conjunction with the 'remote' option does keep the tunnel up and working. However, it seems that I am loosing a layer of security in doing that because it is no longer locked down to a single IP/Port pair.
Again, it works on port 5000 if only the T1 is up and DSL is down. It switches between port 5000 and another port if the T1 and DSL are up.
Thanks for your response and help!
-- James Hammer