Re: Multiple ISPs

2002-09-23 Thread Fraser Campbell

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

2002-09-23 Thread Lukas Eppler
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

2002-09-23 Thread Fraser Campbell
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