Stewart,
I have read your mail twice, and I'm still not quite sure what you are
asking. Some comments and questions inline below....
: i have two machines which are VERY similar (software wise). Both redhat
: 7.2, all
: updates, running 2.4.19-xfs (custom built)
:
: Linux version 2.4.19-xfs (root@xxxxx) (gcc version 2.96 20000731 (Red Hat Linux
: 7.2 2.96-108.7.2)) #3 SMP Mon Nov 11 17:52:11 EST 2002
:
: Linux version 2.4.19-xfs (root@xxxxx) (gcc version 2.96 20000731 (Red Hat Linux
: 7.2 2.96-112.7.2)) #1 Mon Nov 25 15:36:03 EST 2002
:
: omega has two connections to the internet (one is used for hosting our
: web site and mail etc and the other for browsing the web, as it is
: cheaper). I have an iproute2 script set up to acheive this (attached).
Fair enough.
: Delta does not have this script (it is only connected to one internet
: connection). This is the only differnce that isn't hardware (maybe lynx
: isn't installed on delta... but that's all.)
:
: I also have iptables-restore (via the redhat init.d script) setting up
: iptables firewall. I am trying to enable masquerading for one IP in the
: outside world (our freight company uses it or some such thing, and i
: can't proxy it - that i know of). the iptables-restore script is
: attached.
This is very confusing. Perhaps some explanation would help here....
- Do you need to contact a service provider on a public IP?
- Do they expect you to have a particular source address when you hit
their server?
- If so, would this be the "high" quality bandwidth? (eth0)
- What do you mean you need to "enable masquerading for one IP in the
outside world"?
: On Delta, this script works fine - and from my pc, i can connect to the
: remote host (i found the FTP port open, and can telnet to it). However,
: if i set this up on omega, it doesn't (and yes, i change my gateway
: settings).
You are implying that delta and omega are both dual-homed and that each
one is connected to your internal network. Is that accurate?
: client pc is Debian Sid
:
: Linux version 2.4.19-xfs (root@xxxxxxx) (gcc version 2.95.4 20011002 (Debian
: prerelease)) #4 Thu Nov 28 15:06:09 EST 2002
: or
: Linux version 2.5.63 (stewart@xxxxxxx) (gcc version 3.2.3 20030210 (Debian prerelease)) #1 SMP Wed Feb 26 12:48:18 EST 2003
Good to know that linux rules your desktop <smirk>, but irrelevant here.
: using tcpdump, i found the following:
:
: on Omega (the machine with iproute2 enable) the packets come out on the wire
: without their address rewritten (i.e. it says 192.168.0.18 instead of the
: external address)
: on delta, it comes out on the wire with the address rewritten (i.e. correct)
If the problem is with omega, let's focus on omega and forget about delta
(since you don't appear to be complaining about delta's behaviour).
Let's see the following on omega:
# ip address show
# ip route show
# ip rule show
# iptables -t nat -nvL
If you are able, jot down a little netmap of your network, and tell us
what it looks like (just the networks connected to omega, inside and out).
: There are 3 ethernet interfaces
On omega?
: eth0 - internet connection to (more) expensive ISP that does our hosting
: eth1 - intranet connection (local LAN)
: eth2 - internet connection to (less) expensive ISP that we use for web
: browsing etc because it's cheaper.
Nobody ever does that! ;-)
: the aim is to make sure all the connections that come in on eth0 are
: serviced through eth0 (i.e. all the hosting) and all new connections go
: through eth2.
So, you want to make sure that any connections initiated from the Internet
are always returned to the Internet via eth0, correct?
: there is no global NAT thing going on as I am forcing everyone to use
: the proxy.
In that case, all packets are locally generated packets; generated by the
proxy. Just for your reference.....
: There is, however, one app that we use that does neet to have NAT to
: the one IP. This is what i'm trying to get going.
Does this have to happen on delta or omega?
: #!/bin/bash
:
: IF1=eth0
: IF2=eth2
:
: IP1=202.44.184.129
: IP2=10.0.0.2
:
: P1=202.44.184.134
: P2=10.0.0.138
All reasonable....
: P1_NET=202.44.184.135
: P2_NET=10.255.255.255
:
: ip route add $P1_NET dev $IF1 src $IP1 table T1
: ip route add default via $P1 table T1
: ip route add $P2_NET dev $IF2 src $IP2 table T2
: ip route add default via $P2 table T2
Are you trying to create network routes here? These look quite a bit more
like routes to broadcast addresses entered into the routing tables as host
routes....why don't you try something more like this:
P1_NET=202.44.184.128/29
P2_NET=10.0.0.0/8
Those will give you some saner entries for network routes. Was your
split access Internet connectivity functioning as expected before these
recent changes, or is the policy routing stuff all new to this
configuration?
: ip route add $P1_NET dev $IF1 src $IP1
: ip route add $P2_NET dev $IF2 src $IP2
:
: ip route add default via $P2
You are choosing the low cost link (eth2, 10.0.0.138) as your default
route in the main routing table.
: ip rule add from $IP1 table T1
: ip rule add from $IP2 table T2
We can probably help you out here, but I have a large pile of questions
after reading your post. How about sending some more details, and we'll
have a crack at this.
It looks like your split access stuff was acquired from the LARTC
advanced routing HOWTO, but in case you don't have a link to it:
http://lartc.org/howto/
And I have some documentation of split access here:
http://linux-ip.net/
http://linux-ip.net/html/ch-routing.html
http://linux-ip.net/html/adv-multi-internet.html
Good luck,
-Martin
--
Martin A. Brown --- SecurePipe, Inc. --- mabrown@xxxxxxxxxxxxxx
