Hi,
I''ve get a local network with several workstations attached through a
firewall to the internet by two types of connections: one is called
ADSL, which is cheaper, but with lower bandwidth. the other called T3,
faster but more expensive.
I want to enable each workstation from the localnet to choose it''s
connection by setting it''s default gateway to one of the
firewall''s ip
on eth0: 192.168.10.8 for ADSL and 192.168.10.9 for T3. additional each
workstation regardless its gateway ip should be able to access the dmz.
the topology of the net would be something like this:
INTERNET
====================================== |
|
| |
DynIP 212.x.x.195
/------------\ /---------------\
| DSL-ROUTER | | T3-ROUTER |
\------------/ \---------------/
192.168.11.1 62.x.x.89
192.168.11.0/24 62.x.x.88/29
| |
| |
192.168.11.8 62.x.x7.90
192.168.11.0/24 62.x.x.88/29
eth3 eth1 w/ ProxyARP
/---------------\
| FIREWALL |
\---------------/
eth0:1 eth0 eth2 w/ ProxyARP
192.168.10.8 192.168.10.9 62.x.x.90
192.168.10.0/24 62.x.x.88/29
| \
| \
=========================== eth0
LOCALNET 62.x.x.93
62.x.x.88/29
/-----\
| DMZ |
\-----/
My problem is how to route the packages from the localnet to either ADSL
or T3, depending on wether they were received by the ip 192.168.10.8 or
192.168.10.9.
I tried to mark the packages in the postrouting chain of iptables and
send them to different routing tables. but iptables can''t handle
aliased
interfaces like eth0:1 as source devices.
Next step was to set up routing depending on incoming interfaces, but
there was no effect in the actual routing.
my current configurations are:
# ip rule ls
0: from all lookup local
32765: from all iif eth0:1 lookup ADSL
32766: from all lookup main
32767: from all lookup default
# ip route show
62.x.x.89 dev eth1 scope link
62.x.x.88/29 dev eth2 scope link
192.168.11.0/24 dev eth3 proto kernel scope link src 192.168.11.8
192.168.10.0/24 dev eth0 proto kernel scope link src 192.168.10.9
default via 62.x.x.89 dev eth1
# ip route show table ADSL
62.153.117.88/29 dev eth2 scope link
default via 192.168.11.92 dev eth3
Has anyone ideas of solving the problem?
Thanks,
oli
_______________________________________________
LARTC mailing list / LARTC@mailman.ds9a.nl
http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
oli,
Nice ASCII map. (Your mailer didn''t line break it, and it''s
clear.)
: My problem is how to route the packages from the localnet to either
: ADSL or T3, depending on wether they were received by the ip
: 192.168.10.8 or 192.168.10.9. I tried to mark the packages in the
: postrouting chain of iptables and send them to different routing
: tables. but iptables can''t handle aliased interfaces like eth0:1 as
: source devices.
The problem is that the gateway information (client''s chosen
destination
IP address) is lost the moment the packet is encapsulated by the client
and transmitted onto the ethernet.
Packet arrives on your firewall looking something like this:
Frame source: client MAC
Frame dest: firewall eth0 MAC
IP source: client IP
IP dest: real destination IP
The address 192.168.10.8 and 192.168.10.9 are logical IP addresses which
share the same MAC, so you can''t even select on the destination MAC
address, because you can''t assign two hardware addresses to the same
interface simultaneously.
If I had to allow the client to select its default gateway, I''d be
inclined to add another interface. But since I''m a control freak and
BOFH, I''d simply use "ip rule" on the firewall to determine
which client
IP (or outbound service) gets to use bandwidth on my two connections.
I have some documentation available on
http://plorf.net/linux-ip/html/adv-multi-internet.htm
which may be helpful to you in selecting different outbound routes based
on source IP or destination port.
If anybody else has a clever solution about how to accomplish his original
goal, I''d be interested in hearing the idea.
-Martin
: INTERNET
: ====================================== : |
|
: | |
: DynIP 212.x.x.195
: /------------\ /---------------\
: | DSL-ROUTER | | T3-ROUTER |
: \------------/ \---------------/
: 192.168.11.1 62.x.x.89
: 192.168.11.0/24 62.x.x.88/29
: | |
: | |
: 192.168.11.8 62.x.x7.90
: 192.168.11.0/24 62.x.x.88/29
: eth3 eth1 w/ ProxyARP
: /---------------\
: | FIREWALL |
: \---------------/
: eth0:1 eth0 eth2 w/ ProxyARP
: 192.168.10.8 192.168.10.9 62.x.x.90
: 192.168.10.0/24 62.x.x.88/29
: | \
: | \
: =========================== eth0
: LOCALNET 62.x.x.93
: 62.x.x.88/29
: /-----\
: | DMZ |
: \-----/
--
Martin A. Brown --- SecurePipe, Inc. --- mabrown@securepipe.com
_______________________________________________
LARTC mailing list / LARTC@mailman.ds9a.nl
http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
Hi Martin.>If I had to allow the client to select its default gateway, I''d be >inclined to add another interface. >I''ve already tried this out, but the kernel gets really confused with this configuration. Incoming packets were abriatly answered by one or the other interface. I learned from the net that it''s just not possible to to manage, if both interfaces are connected to the same section (eg. switch) of the subnet. The config of eth1 and eth2 just works, because both parts of the subnet are phsically seperated and packets to 62.x.x.90 only arrive on one of the two interfaces. If someone''s got a solution to the problem ''two interfaces on the same subnet'', let me know.>But since I''m a control freak and >BOFH, I''d simply use "ip rule" on the firewall to determine which client >IP (or outbound service) gets to use bandwidth on my two connections. > >I have some documentation available on > > http://plorf.net/linux-ip/html/adv-multi-internet.htm > >which may be helpful to you in selecting different outbound routes based >on source IP or destination port. > >Source based routing would only be a second best solution. My task is to let the user choose the outbound route. In this case I would have to built a kind of user-interface to the firewall-script. I think that would be a bad idea. On the other hand I want prevent people asking me to switch theirs connection. But thanks so far. More hints are welcome. oli> : INTERNET > : ======================================> : | | > : | | > : DynIP 212.x.x.195 > : /------------\ /---------------\ > : | DSL-ROUTER | | T3-ROUTER | > : \------------/ \---------------/ > : 192.168.11.1 62.x.x.89 > : 192.168.11.0/24 62.x.x.88/29 > : | | > : | | > : 192.168.11.8 62.x.x7.90 > : 192.168.11.0/24 62.x.x.88/29 > : eth3 eth1 w/ ProxyARP > : /---------------\ > : | FIREWALL | > : \---------------/ > : eth0:1 eth0 eth2 w/ ProxyARP > : 192.168.10.8 192.168.10.9 62.x.x.90 > : 192.168.10.0/24 62.x.x.88/29 > : | \ > : | \ > : =========================== eth0 > : LOCALNET 62.x.x.93 > : 62.x.x.88/29 > : /-----\ > : | DMZ | > : \-----/ > > > > >_______________________________________________ LARTC mailing list / LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
Hi there Oliver, OK, so you''re definitely up to snuff on the issues implied by your config. I may be able to help you out on the "two interfaces on the same subnet" problem. At least for outbound packets. : If someone''s got a solution to the problem ''two interfaces on the same : subnet'', let me know. I''ve written a little bit about the ARP flux problem here: http://plorf.net/linux-ip/html/ch-ether.htm#ETHER-ARP-FLUX Basically there are four solutions: /proc/sys/net/ipv4/conf/*/rp_filter # kernel 2.4 only /proc/sys/net/ipv4/conf/*/hidden # patch to 2.4; in 2.2.14+ ip arp # patch to 2.4 and iproute2 ip route add <route> noarp # patch to 2.4 and iproute2 For description of the rp_filter solution see the IP sysctl tutorial: http://ipsysctl-tutorial.frozentux.net/ipsysctl-tutorial.html#AEN616 For a description of the other three, see Julian''s site: http://www.linuxvirtualserver.org/~julian/ Once you''ve solved the ARP flux problem (two NICs on one segment), you''ll be able to do something like this: # ip rule add iif eth0 table main # ip rule add iif eth4 table t3 Then the main routing table would have a route out the ADSL line, and you could create table t3 with a route out your main connection. With all of that said, your firewall may send the inbound packets back to the clients via the "wrong" interface, but this should not matter, as the client machines will continue to cache the IP/MAC mapping for outbound packets--and these are the important ones for your configuration. I haven''t ever tried this so I don''t know what wrinkles you should expect, but....it should work (famous last words). : Source based routing would only be a second best solution. My task is to : let the user choose the outbound route. In this case I would have to : built a kind of user-interface to the firewall-script. I think that : would be a bad idea. On the other hand I want prevent people asking me : to switch theirs connection. What!? You are trying to lighten your workload? Sacrilege! :) -Martin -- Martin A. Brown --- SecurePipe, Inc. --- mabrown@securepipe.com _______________________________________________ LARTC mailing list / LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
I''ve been subbing this list for a couple of months now, knowing this day would come :-) I too am trying to do an equalize/next hop for 2 adsl lines. At the moment though I am testing with 1 2MB adsl modem and an ether connection to a switch from a second 2MB line. I am doing it from the *outside* via ssh, which makes it a little more difficult, since when I mess up I lose access until I can get someone to restart the network without my changes... I began by using the example from lartc.org, combined with a cron to undo my changes every half hour, but moved to following this page from sysadmin magazine: http://www.samag.com/documents/sam0201h/ For some reason I got a better sense of what I was trying to do from it, plus it included a section on just where to place the new rules into the system scripts. It did not say just where to place the section for ifup-routes though. I think I''ve got it pretty close, but since I just locked myself out again... It''s a mandrake 9.0 box and I didn''t see where to prevent a default route from being set when it brings up ppp0 on the adsl line. I sort of hoped that my default routes would get set first and force the other to fail with the Exists error. Since I couldn''t find it, I don''t know in what order it gets run. I think that''s where I messed up, but I can''t get back in to read the logs right now. Also, the above article uses ip to route to the lan, and I had intended/understood that I would masquerade to it later. Which is the correct approach then? I will want to move on to tc when I finally get this part working. from the article: advanced eth0 10.0.0.0/24 via 10.0.0.1 table 1 advanced eth0 10.0.0.0/24 via 10.0.0.1 table 2 advanced eth1 0/0 via 63.89.102.1 table 1 advanced eth2 0/0 via 65.3.17.1 table 2 Where eth0 is their lan and eth1/2 are isp. They have a new section in ifup-routes grepping a file named static-routes for ''^advanced''. -- Regards, Paul Evans _______________________________________________ LARTC mailing list / LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
Paul, On Thu, 2003-01-30 at 15:58, Paul Evans wrote:> I''ve been subbing this list for a couple of months now, knowing this day would > come :-)My gut says I was not alone, you are not alone, and others will eventually be going down this path as well.> I too am trying to do an equalize/next hop for 2 adsl lines. At the moment > though I am testing with 1 2MB adsl modem and an ether connection to a switch > from a second 2MB line. > > I am doing it from the *outside* via ssh, which makes it a little more > difficult, since when I mess up I lose access until I can get someone to > restart the network without my changes...Ouch, that will slow things down during testing.> I began by using the example from lartc.org, combined with a cron to undo my > changes every half hour, but moved to following this page from sysadmin > magazine: > http://www.samag.com/documents/sam0201h/Good article, I cam across it as well. However it really only is accurate on the DNS point of view from the outside world. For things to work the other way around, from the inside going out you will need the nano-how-to and possible Julian''s patches applied to a custom compiled kernel. http://www.linuxvirtualserver.org/~julian/#routes> For some reason I got a better sense of what I was trying to do from it, plus > it included a section on just where to place the new rules into the system > scripts. It did not say just where to place the section for ifup-routes > though.When doing something of this nature I recommend not using any provided networking scripts and make your own. It''s fairly straight forward and easy to do. Just put all your commands into a function that can be called from outside of the script. Like ./mynetwork.sh start will call the start function.> I think I''ve got it pretty close, but since I just locked myself out again...That sucks. :)> It''s a mandrake 9.0 box and I didn''t see where to prevent a default route from > being set when it brings up ppp0 on the adsl line. I sort of hoped that my > default routes would get set first and force the other to fail with the > Exists error. Since I couldn''t find it, I don''t know in what order it gets > run. I think that''s where I messed up, but I can''t get back in to read the > logs right now.Like is said make your own scripts and do not use the originals for now, if possible. I think that your doing this from the outside may require you to use the default ones until you get things working. Then make your own and forget about the default ones.> Also, the above article uses ip to route to the lan, and I had > intended/understood that I would masquerade to it later. Which is the correct > approach then? I will want to move on to tc when I finally get this part > working.The way it works for me, and to my knowledge the only way it works is by masquerading. That''s where the patches make things work. However I thought I saw a comment from Julian that masquerading was not necessary? I thought it was? I would imagine Julian will set me straight one way or the other. ;)> from the article: > > advanced eth0 10.0.0.0/24 via 10.0.0.1 table 1 > advanced eth0 10.0.0.0/24 via 10.0.0.1 table 2 > advanced eth1 0/0 via 63.89.102.1 table 1 > advanced eth2 0/0 via 65.3.17.1 table 2 > > Where eth0 is their lan and eth1/2 are isp. They have a new section in > ifup-routes grepping a file named static-routes for ''^advanced''.This stuff forget from the sys-admin article and stick to the routing rules on the nano-how-to. The only part of the sys-admin article that I used and recommend others to use is the DNS aspect for redundancy/load balancing from the outside world. Although most of the same info with other examples can be found in the BIND manual. -- Sincerely, William L. Thomson Jr. Support Group Obsidian-Studios Inc. 439 Amber Way Petaluma, Ca. 94952 Phone 707.766.9509 Fax 707.766.8989 http://www.obsidian-studios.com _______________________________________________ LARTC mailing list / LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
At 05:58 PM 1/30/2003, Paul Evans wrote: << Snip >>> >I am doing it from the *outside* via ssh, which makes it a little more >difficult, since when I mess up I lose access until I can get someone to >restart the network without my changes...Might I suggest mgetty and a POTS line so you can "phone home" and undo the damage yourself. ;-) John <*>
Paul, On Thu, 2003-01-30 at 16:59, Paul Evans wrote:> Yes, the usual learning cycle of break/repair, break/repair cycle takes a > looong time.I sure spent my time in the trenches.> Thanks very much. I suppose it''s back to my old script then. I was stuck with > a ''file exists error'', because of the existing default route. Of course, if I > were to delete it, I''d suddenly not be ''there'' anymore to apply the script. > Maybe I can do both via cron instead.In that case you will want to use two different scripts. The existing one and the new one. Have cron simply restart the network every so often probably like you are. Also in part of your script is sounds like you need to flush out everything the default network script adds that you do not want.> Thanks yet again, I skipped Julian''s page, because I thought it was just for > the patch. I will go and read it. When I finally get my head around this > part, I will probably have to consider recompiling the kernel and applying > the patch (I think we''re talking about the one to eliminate the route > caching).Yes, I tried to play with the cache settings directly, but no combo made things work like the patches. You must also adhere to the nano-how-to rules on routes and such.> I''m familiar with bash functions and I will follow your advice, for me I am > still trying to untangle all the nested calling of the many and varied > scripts that come into play when bringing up all the interfaces. Which do you > recommend my redoing exactly. I mean the existing one for network, ifxxup, > adsl-start are all doing fine the way they are (except for the bit where I > don''t know how to prevent a default route being set by adsl-start that is). I > had hoped I could end up with a single script from, say rc.local or > something. Not to be huh? ( I still haven''t read the nano you ref''ed > earlier).You can still use your existing network script, just make another one that removes the default ADSL route and anything else that is getting in your way, and then run your commands to get things working your way. Once you are done with your script put it in /etc/rc.d/init.d and add a symbolic link in the proper run level(s) with the necessary startup number. Probably just after the standard network script is run. If you want a single one, add everything you need to your new script and use instead of the default. Although depending on the type of ADSL, PPOE type, you may want to keep and use the default startup script. There is nothing wrong with two, but it is Linux so do what you like and put things were you want them. Make sure to read the nano-how-to or at least make sure all your rules are exactly the same within reason. I tried some deviations, but all failed. Obviously you do need to use the exact IP''s as in the example, but use the same rules, and commands using your IP info.> > The way it works for me, and to my knowledge the only way it works is by > > masquerading. That''s where the patches make things work. > Ok good. That part realy confused me after all the reading I''ve done on stef''s > site etc.That part still some what confuses me. What is clear is I had a goal and was able to reach it. Masquerading was not a requirement for me, but I did not mind doing it as well. I simply ended up with two rounds of NAT/PAT or two back to back firewalls on either link. More on my config can be found in the archives, but feel free to contact me directly for any questions and specific configuration examples. -- Sincerely, William L. Thomson Jr. Support Group Obsidian-Studios Inc. 439 Amber Way Petaluma, Ca. 94952 Phone 707.766.9509 Fax 707.766.8989 http://www.obsidian-studios.com _______________________________________________ LARTC mailing list / LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/