Re: Multiple ISPs
On Mon, 2002-09-23 at 17:33, Lukas Eppler wrote: > Has anyone of you set up a NAT server connecting to more than one ISP? Yes, in a few different places. > We are switching isp's and I wanted to avoid downtime by using both > networks simultaneously for some time. It's a good option. > So what do you suggest, should I > 1) Write everything by hand, not using ipmasq, Not sure on what ipmasq does (never used it), so long as it handles masquerading outbound traffic you'll probably be ok. > 2) Extend ipmasq's rules somehow to fire the routing tables up correctly > 3) Just run a script after ipmasq to introduce Yes. > root# ip route show > xx.yy.zz.16/29 dev eth2 proto kernel scope link src xx.yy.zz.17 > aa.bb.cc.160/28 dev eth0 proto kernel scope link src aa.bb.cc.162 > 10.0.0.0/8 dev eth1 proto kernel scope link src 10.0.0.1 > default via aa.bb.cc.161 dev eth0 Roughly speaking this is how I have done it, hopefully you find the example useful: #/bin/sh #--- Start of example ---# # Routing table for each net, containing appropriate default route ip route add default via xx.yy.zz.17 table 10 ip route add default via aa.bb.cc.161 table 20 # start priority of rules PRI=1000 # Anything going inside must be routed normally INT_NETS='192.168.0.0/24 192.168.16.0/22' for net in $INT_NETS; do ip rule add to $net lookup main pri $PRI PRI=`expr $PRI + 10` done # Force specific traffic to go the way you want it # DMZ server 192.168.0.10 goes out on old connection ip rule add from 192.168.0.10 lookup 10 map-to xx.yy.zz.18 pri $PRI # DMZ server 192.168.0.11 goes out new connection PRI=`expr $PRI + 10` ip rule add from 192.168.0.11 lookup 20 map-to aa.bb.cc.164 pri $PRI # Force LAN to go out old network for now PRI=`expr $PRI + 10` ip rule add from 192.168.16.0/22 lookup 10 map-to xx.yy.zz.19 pri $PRI # Make sure any leftovers go out the right way PRI=`expr $PRI + 10` ip rule add from xx.yy.zz.16/29 lookup 10 pri $PRI ip rule add from aa.bb.cc.160/28 lookup 20 pri $PRI # Flush routing cache to immediately activate changes ip route flush cache #--- End of example ---# One issue we have run into is that Linux masquerading seems to remember how it NATed packets and ignore changes requested in NATing via ip rules. For example here on my firewall is a NATed connection going to google: [EMAIL PROTECTED] /root]# ipchains -M -L -n|grep 216.239.51.101 TCP 14:58.15 10.142.254.1 216.239.51.101 35293 (62553) -> 80 If I decide to route 10.142.254.1 through a different connection with a rule like 'ip rule add from 10.142.254.1 lookup 20 map-to aa.bb.cc.165 pri $PRI' it wouldn't work until all Masquerading entries had cleared. The packets would actually be sent out the new route but they would have the old source adddress still (that which it was masqueraded to at the time of the still living masquerade entries). This problem makes it very difficult to change routing on the fly, I haven't found any way to flush masqueraded entries (please if there is one let me know). Hopefully the 2.4 linux kernel, and iptables, handle this issue better. The solution we use is to have servers multi-homed internally as well as externally. If you don't have incoming traffic (port forwarded) then this probably won't be an issue. This might be too much information so I'll stop now, hopefully I made at least a little sense. If you have more questions just followup to the list and I will try to respond. > default via xx.yy.zz.22 dev eth2 src xx.yy.zz.17 I've never had any luck with the src argument either. Fraser
Multiple ISPs
Has anyone of you set up a NAT server connecting to more than one ISP? We are switching isp's and I wanted to avoid downtime by using both networks simultaneously for some time. My preliminary findings: I have two cards connected to cable modems and have read the brillant Linux Advanced Routing and Traffic Control Howto, which explains how to set up a linux machine to connect to more than one ISP, however, it starts from scratch using the iproute package. I have handled the NAT of my internal network with the ipmasq debian package and I like not having to write every rule by hand (especially when a ppp link comes up, which is the case for me with vpn connections). I'm not worried about load balancing or anything like that yet, I would only like to be visible on both networks and route all masqeraded traffic through one of the links. So what do you suggest, should I 1) Write everything by hand, not using ipmasq, 2) Extend ipmasq's rules somehow to fire the routing tables up correctly 3) Just run a script after ipmasq to introduce For your information, that's how far I came: root# ip route show xx.yy.zz.16/29 dev eth2 proto kernel scope link src xx.yy.zz.17 aa.bb.cc.160/28 dev eth0 proto kernel scope link src aa.bb.cc.162 10.0.0.0/8 dev eth1 proto kernel scope link src 10.0.0.1 default via aa.bb.cc.161 dev eth0 I tried introducing a second default route: default via xx.yy.zz.22 dev eth2 src xx.yy.zz.17 The second default route is never reached, so my idea of avoiding routing tables using a src for the gateway didn't work. Swapping the default routes gets eth2 pinging but eth0 switches off. I can see the pings on the card without a default gateway attached coming in (with tcpdump) but the kernel seems to reply the ping on the default gateway. root# grep eth0 /etc/ipmasq/rules/A01precompute.rul export EXTERNAL="eth0 eth2" [blue:~] root# ifconfig eth0 Link encap:Ethernet HWaddr 00:04:75:AD:6B:C9 inet addr:aa.bb.cc.162 Bcast: aa.bb.cc.175 Mask:255.255.255.240 UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:3249800 errors:0 dropped:0 overruns:0 frame:0 TX packets:3410039 errors:0 dropped:0 overruns:0 carrier:42 collisions:7905 RX bytes:1235492433 (1.1 GiB) TX bytes:1549390655 (1.4 GiB) eth1 Link encap:Ethernet HWaddr 00:04:76:0E:C1:1D inet addr:10.0.0.1 Bcast:10.255.255.255 Mask:255.0.0.0 EtherTalk Phase 2 addr:65280/113 UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:5240114 errors:0 dropped:0 overruns:1 frame:0 TX packets:4930194 errors:0 dropped:0 overruns:0 carrier:1579 collisions:0 RX bytes:2028758870 (1.8 GiB) TX bytes:1876902432 (1.7 GiB) eth2 Link encap:Ethernet HWaddr 00:D0:B7:79:51:9F inet addr: xx.yy.zz.17 Bcast: xx.yy.zz.23 Mask:255.255.255.248 UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:11565 errors:0 dropped:0 overruns:0 frame:0 TX packets:3579 errors:0 dropped:0 overruns:0 carrier:0 collisions:1 RX bytes:3456804 (3.2 MiB) TX bytes:458136 (447.3 KiB) loLink encap:Local Loopback inet addr:127.0.0.1 Mask:255.0.0.0 EtherTalk Phase 2 addr:0/0 UP LOOPBACK RUNNING MTU:16436 Metric:1 RX packets:1083536 errors:0 dropped:0 overruns:0 frame:0 TX packets:1083536 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 RX bytes:139937541 (133.4 MiB) TX bytes:139937541 (133.4 MiB) Thank you for your help.
Re: Multiple ISPs
On Mon, 2002-09-23 at 17:33, Lukas Eppler wrote: > Has anyone of you set up a NAT server connecting to more than one ISP? Yes, in a few different places. > We are switching isp's and I wanted to avoid downtime by using both > networks simultaneously for some time. It's a good option. > So what do you suggest, should I > 1) Write everything by hand, not using ipmasq, Not sure on what ipmasq does (never used it), so long as it handles masquerading outbound traffic you'll probably be ok. > 2) Extend ipmasq's rules somehow to fire the routing tables up correctly > 3) Just run a script after ipmasq to introduce Yes. > root# ip route show > xx.yy.zz.16/29 dev eth2 proto kernel scope link src xx.yy.zz.17 > aa.bb.cc.160/28 dev eth0 proto kernel scope link src aa.bb.cc.162 > 10.0.0.0/8 dev eth1 proto kernel scope link src 10.0.0.1 > default via aa.bb.cc.161 dev eth0 Roughly speaking this is how I have done it, hopefully you find the example useful: #/bin/sh #--- Start of example ---# # Routing table for each net, containing appropriate default route ip route add default via xx.yy.zz.17 table 10 ip route add default via aa.bb.cc.161 table 20 # start priority of rules PRI=1000 # Anything going inside must be routed normally INT_NETS='192.168.0.0/24 192.168.16.0/22' for net in $INT_NETS; do ip rule add to $net lookup main pri $PRI PRI=`expr $PRI + 10` done # Force specific traffic to go the way you want it # DMZ server 192.168.0.10 goes out on old connection ip rule add from 192.168.0.10 lookup 10 map-to xx.yy.zz.18 pri $PRI # DMZ server 192.168.0.11 goes out new connection PRI=`expr $PRI + 10` ip rule add from 192.168.0.11 lookup 20 map-to aa.bb.cc.164 pri $PRI # Force LAN to go out old network for now PRI=`expr $PRI + 10` ip rule add from 192.168.16.0/22 lookup 10 map-to xx.yy.zz.19 pri $PRI # Make sure any leftovers go out the right way PRI=`expr $PRI + 10` ip rule add from xx.yy.zz.16/29 lookup 10 pri $PRI ip rule add from aa.bb.cc.160/28 lookup 20 pri $PRI # Flush routing cache to immediately activate changes ip route flush cache #--- End of example ---# One issue we have run into is that Linux masquerading seems to remember how it NATed packets and ignore changes requested in NATing via ip rules. For example here on my firewall is a NATed connection going to google: [root@somewhere /root]# ipchains -M -L -n|grep 216.239.51.101 TCP 14:58.15 10.142.254.1 216.239.51.101 35293 (62553) -> 80 If I decide to route 10.142.254.1 through a different connection with a rule like 'ip rule add from 10.142.254.1 lookup 20 map-to aa.bb.cc.165 pri $PRI' it wouldn't work until all Masquerading entries had cleared. The packets would actually be sent out the new route but they would have the old source adddress still (that which it was masqueraded to at the time of the still living masquerade entries). This problem makes it very difficult to change routing on the fly, I haven't found any way to flush masqueraded entries (please if there is one let me know). Hopefully the 2.4 linux kernel, and iptables, handle this issue better. The solution we use is to have servers multi-homed internally as well as externally. If you don't have incoming traffic (port forwarded) then this probably won't be an issue. This might be too much information so I'll stop now, hopefully I made at least a little sense. If you have more questions just followup to the list and I will try to respond. > default via xx.yy.zz.22 dev eth2 src xx.yy.zz.17 I've never had any luck with the src argument either. Fraser -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Multiple ISPs
Has anyone of you set up a NAT server connecting to more than one ISP? We are switching isp's and I wanted to avoid downtime by using both networks simultaneously for some time. My preliminary findings: I have two cards connected to cable modems and have read the brillant Linux Advanced Routing and Traffic Control Howto, which explains how to set up a linux machine to connect to more than one ISP, however, it starts from scratch using the iproute package. I have handled the NAT of my internal network with the ipmasq debian package and I like not having to write every rule by hand (especially when a ppp link comes up, which is the case for me with vpn connections). I'm not worried about load balancing or anything like that yet, I would only like to be visible on both networks and route all masqeraded traffic through one of the links. So what do you suggest, should I 1) Write everything by hand, not using ipmasq, 2) Extend ipmasq's rules somehow to fire the routing tables up correctly 3) Just run a script after ipmasq to introduce For your information, that's how far I came: root# ip route show xx.yy.zz.16/29 dev eth2 proto kernel scope link src xx.yy.zz.17 aa.bb.cc.160/28 dev eth0 proto kernel scope link src aa.bb.cc.162 10.0.0.0/8 dev eth1 proto kernel scope link src 10.0.0.1 default via aa.bb.cc.161 dev eth0 I tried introducing a second default route: default via xx.yy.zz.22 dev eth2 src xx.yy.zz.17 The second default route is never reached, so my idea of avoiding routing tables using a src for the gateway didn't work. Swapping the default routes gets eth2 pinging but eth0 switches off. I can see the pings on the card without a default gateway attached coming in (with tcpdump) but the kernel seems to reply the ping on the default gateway. root# grep eth0 /etc/ipmasq/rules/A01precompute.rul export EXTERNAL="eth0 eth2" [blue:~] root# ifconfig eth0 Link encap:Ethernet HWaddr 00:04:75:AD:6B:C9 inet addr:aa.bb.cc.162 Bcast: aa.bb.cc.175 Mask:255.255.255.240 UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:3249800 errors:0 dropped:0 overruns:0 frame:0 TX packets:3410039 errors:0 dropped:0 overruns:0 carrier:42 collisions:7905 RX bytes:1235492433 (1.1 GiB) TX bytes:1549390655 (1.4 GiB) eth1 Link encap:Ethernet HWaddr 00:04:76:0E:C1:1D inet addr:10.0.0.1 Bcast:10.255.255.255 Mask:255.0.0.0 EtherTalk Phase 2 addr:65280/113 UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:5240114 errors:0 dropped:0 overruns:1 frame:0 TX packets:4930194 errors:0 dropped:0 overruns:0 carrier:1579 collisions:0 RX bytes:2028758870 (1.8 GiB) TX bytes:1876902432 (1.7 GiB) eth2 Link encap:Ethernet HWaddr 00:D0:B7:79:51:9F inet addr: xx.yy.zz.17 Bcast: xx.yy.zz.23 Mask:255.255.255.248 UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:11565 errors:0 dropped:0 overruns:0 frame:0 TX packets:3579 errors:0 dropped:0 overruns:0 carrier:0 collisions:1 RX bytes:3456804 (3.2 MiB) TX bytes:458136 (447.3 KiB) loLink encap:Local Loopback inet addr:127.0.0.1 Mask:255.0.0.0 EtherTalk Phase 2 addr:0/0 UP LOOPBACK RUNNING MTU:16436 Metric:1 RX packets:1083536 errors:0 dropped:0 overruns:0 frame:0 TX packets:1083536 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 RX bytes:139937541 (133.4 MiB) TX bytes:139937541 (133.4 MiB) Thank you for your help. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: about Woody ?
On Mon, 23 Sep 2002 at 17:25:10 +, Julián Mu?oz wrote: > On Mon, 23 Sep 2002, Tomasz Papszun wrote: > > > Woody is stable for 2 months now! :-) . > > Yes, I know. Sorry for my bad english ;-) (By the way, do you think it's > enough 2 months ?) Yes, I think so. On the other hand, I hate some of new features(?) (bugs?) in woody. For instance, unification of authorization in phpmyadmin and apache - I no longer can have checking by means of .htaccess separated from checking by means of mysql database. We searched the Net for a solution. Other people are angry with it as well but seems that noone knows how to get to the previous way of operation. There are some other applications that changed their operation in such way that some vital subsystem (modified by me) of a server stopped working :-(( . The problem with potato is that in some near future, security fixes won't be released anymore. So it's better to upgrade when it's convenient, not when you will _have_ to do it quickly. > Well, I would like to evaluate the cost of transition. And also, I'd like > to be sure when to change. > > Potato is feature frozen, and I liked this really, because I need > stability, and only fixes for the important bugs. > What about Woody ? > > > See http://www.debian.org/releases/stable/ > > Of course we use it. > > Sorry, it is not so obvious to me ! ( Ignorant I am :-) Hope it helps -- Tomasz Papszun SysAdm @ TP S.A. Lodz, Poland | And it's only [EMAIL PROTECTED] http://www.lodz.tpsa.pl/ | ones and zeros.
Re: about Woody ?
Potato is feature frozen, and I liked this really, because I need stability, and only fixes for the important bugs. What about Woody ? you can set woody up so you only get security updates. -- Bernie Berg| [EMAIL PROTECTED] Network Administrator | Office:(605)362-6361 Circa Design Company | Cell:(605)201-3891
Re: about Woody ?
On Mon, 23 Sep 2002, Tomasz Papszun wrote: > Woody is stable for 2 months now! :-) . Yes, I know. Sorry for my bad english ;-) (By the way, do you think it's enough 2 months ?) Well, I would like to evaluate the cost of transition. And also, I'd like to be sure when to change. Potato is feature frozen, and I liked this really, because I need stability, and only fixes for the important bugs. What about Woody ? > See http://www.debian.org/releases/stable/ > Of course we use it. Sorry, it is not so obvious to me ! ( Ignorant I am :-) -- __o _ \<_ (_)/(_) Saludos de Julián -.- DVD-record Tools for linux http://www.freesoftware.fsf.org/dvdrtools/
Re: about Woody ?
I can't remember when I started using woody, but it has been very usable for a LONG time eventhough it has only been released as "stable" for a couple months. anyway, yes I use it. Julián Muñoz wrote: Hello, What do you think about woody becoming "stable" ? Are you using it ? Is it feature frozen ?? -- Bernie Berg| [EMAIL PROTECTED] Network Administrator | Office:(605)362-6361 Circa Design Company | Cell:(605)201-3891
Re: about Woody ?
On Mon, 23 Sep 2002 at 17:09:32 +, Julián Mu?oz wrote: > > Hello, > > What do you think about woody becoming "stable" ? > Are you using it ? > > Is it feature frozen ?? Woody is stable for 2 months now! :-) . See http://www.debian.org/releases/stable/ Of course we use it. -- Tomasz Papszun SysAdm @ TP S.A. Lodz, Poland | And it's only [EMAIL PROTECTED] http://www.lodz.tpsa.pl/ | ones and zeros.
about Woody ?
Hello, What do you think about woody becoming "stable" ? Are you using it ? Is it feature frozen ?? -- __o _ \<_ (_)/(_) Saludos de Julián -.- DVD-record Tools for linux http://www.freesoftware.fsf.org/dvdrtools/
Re: about Woody ?
On Mon, 23 Sep 2002 at 17:25:10 +, Julián Mu?oz wrote: > On Mon, 23 Sep 2002, Tomasz Papszun wrote: > > > Woody is stable for 2 months now! :-) . > > Yes, I know. Sorry for my bad english ;-) (By the way, do you think it's > enough 2 months ?) Yes, I think so. On the other hand, I hate some of new features(?) (bugs?) in woody. For instance, unification of authorization in phpmyadmin and apache - I no longer can have checking by means of .htaccess separated from checking by means of mysql database. We searched the Net for a solution. Other people are angry with it as well but seems that noone knows how to get to the previous way of operation. There are some other applications that changed their operation in such way that some vital subsystem (modified by me) of a server stopped working :-(( . The problem with potato is that in some near future, security fixes won't be released anymore. So it's better to upgrade when it's convenient, not when you will _have_ to do it quickly. > Well, I would like to evaluate the cost of transition. And also, I'd like > to be sure when to change. > > Potato is feature frozen, and I liked this really, because I need > stability, and only fixes for the important bugs. > What about Woody ? > > > See http://www.debian.org/releases/stable/ > > Of course we use it. > > Sorry, it is not so obvious to me ! ( Ignorant I am :-) Hope it helps -- Tomasz Papszun SysAdm @ TP S.A. Lodz, Poland | And it's only [EMAIL PROTECTED] http://www.lodz.tpsa.pl/ | ones and zeros. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: about Woody ?
> Potato is feature frozen, and I liked this really, because I need > stability, and only fixes for the important bugs. > What about Woody ? > you can set woody up so you only get security updates. -- Bernie Berg| [EMAIL PROTECTED] Network Administrator | Office:(605)362-6361 Circa Design Company | Cell:(605)201-3891 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: about Woody ?
On Mon, 23 Sep 2002, Tomasz Papszun wrote: > Woody is stable for 2 months now! :-) . Yes, I know. Sorry for my bad english ;-) (By the way, do you think it's enough 2 months ?) Well, I would like to evaluate the cost of transition. And also, I'd like to be sure when to change. Potato is feature frozen, and I liked this really, because I need stability, and only fixes for the important bugs. What about Woody ? > See http://www.debian.org/releases/stable/ > Of course we use it. Sorry, it is not so obvious to me ! ( Ignorant I am :-) -- __o _ \<_ (_)/(_) Saludos de Julián -.- DVD-record Tools for linux http://www.freesoftware.fsf.org/dvdrtools/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: about Woody ?
I can't remember when I started using woody, but it has been very usable for a LONG time eventhough it has only been released as "stable" for a couple months. anyway, yes I use it. Julián Muñoz wrote: > Hello, > > What do you think about woody becoming "stable" ? > Are you using it ? > > Is it feature frozen ?? > > -- Bernie Berg| [EMAIL PROTECTED] Network Administrator | Office:(605)362-6361 Circa Design Company | Cell:(605)201-3891 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: about Woody ?
On Mon, 23 Sep 2002 at 17:09:32 +, Julián Mu?oz wrote: > > Hello, > > What do you think about woody becoming "stable" ? > Are you using it ? > > Is it feature frozen ?? Woody is stable for 2 months now! :-) . See http://www.debian.org/releases/stable/ Of course we use it. -- Tomasz Papszun SysAdm @ TP S.A. Lodz, Poland | And it's only [EMAIL PROTECTED] http://www.lodz.tpsa.pl/ | ones and zeros. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
about Woody ?
Hello, What do you think about woody becoming "stable" ? Are you using it ? Is it feature frozen ?? -- __o _ \<_ (_)/(_) Saludos de Julián -.- DVD-record Tools for linux http://www.freesoftware.fsf.org/dvdrtools/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
http://Worldsat.rtfm.be
Après Http://Xsat.rtfm.be, nous revoila avec un nouveau Site et de nouvelles aventures ... Le Site est encore en cours de réalisation, mais le Forum est déja ouvert... Merci de passer nous voir à l'occasion Déjà disponible Les Firmwares de Toute la gamme des Recepteurs Worldsat. After Http://Xsat.rtfm.be, we come back with a new Site and from new adventures... The Site is still in progress, but the Forum is already opened... Please cross to see us occasionally Already available firmwares of decoders Worldsat PatrickWST from WorldSat Team Http://Worldsat.rtfm.be
http://Worldsat.rtfm.be
Après Http://Xsat.rtfm.be, nous revoila avec un nouveau Site et de nouvelles aventures ... Le Site est encore en cours de réalisation, mais le Forum est déja ouvert... Merci de passer nous voir à l'occasion Déjà disponible Les Firmwares de Toute la gamme des Recepteurs Worldsat. After Http://Xsat.rtfm.be, we come back with a new Site and from new adventures... The Site is still in progress, but the Forum is already opened... Please cross to see us occasionally Already available firmwares of decoders Worldsat PatrickWST from WorldSat Team Http://Worldsat.rtfm.be -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
