(i posted this in bugzilla, but was told to post it here - bug #52) 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@omega) (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@delta) (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). 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. 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). client pc is Debian Sid Linux version 2.4.19-xfs (root@stewart) (gcc version 2.95.4 20011002 (Debian prerelease)) #4 Thu Nov 28 15:06:09 EST 2002 or Linux version 2.5.63 (stewart@stewart) (gcc version 3.2.3 20030210 (Debian prerelease)) #1 SMP Wed Feb 26 12:48:18 EST 2003 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) There are 3 ethernet interfaces 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. 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. there is no global NAT thing going on as I am forcing everyone to use the proxy. 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. ---- ROUTING SETUP SCRIPT ---- #!/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 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 ip route add $P1_NET dev $IF1 src $IP1 ip route add $P2_NET dev $IF2 src $IP2 ip route add default via $P2 ip rule add from $IP1 table T1 ip rule add from $IP2 table T2 ---- IPTABLES SETUP SCRIPT ---- # Generated by iptables-save v1.2.5 on Wed Feb 19 12:53:31 2003 *nat :PREROUTING ACCEPT [99:6653] :POSTROUTING ACCEPT [18:1457] :OUTPUT ACCEPT [18:1457] [0:0] -A POSTROUTING -d 203.1.223.9 -o eth1 -j MASQUERADE [0:0] -A POSTROUTING -d www.apple.com -o eth1 -j MASQUERADE COMMIT # Completed on Wed Feb 19 12:53:31 2003 # Generated by iptables-save v1.2.5 on Wed Feb 19 12:53:31 2003 *mangle :PREROUTING ACCEPT [1322:99920] :INPUT ACCEPT [28635:6719576] :FORWARD ACCEPT [1187:95014] :OUTPUT ACCEPT [1185:711578] :POSTROUTING ACCEPT [26447:11202088] COMMIT # Completed on Wed Feb 19 12:53:31 2003 # Generated by iptables-save v1.2.5 on Wed Feb 19 12:53:31 2003 *filter :INPUT ACCEPT [880:68811] :FORWARD ACCEPT [0:0] :OUTPUT ACCEPT [1185:711578] :block - [0:0] [315:22060] -A INPUT -i eth0 -p tcp -m tcp --dport 22 -j ACCEPT [0:0] -A INPUT -i eth0 -p tcp -m tcp --dport 80 -j ACCEPT [0:0] -A INPUT -i eth0 -p tcp -m tcp --dport 443 -j ACCEPT [0:0] -A INPUT -i eth0 -p tcp -m tcp --dport 25 -j ACCEPT [0:0] -A INPUT -i eth0 -p tcp -m tcp --dport 110 -j ACCEPT [0:0] -A INPUT -i eth0 -p tcp -m tcp --dport 995 -j ACCEPT [0:0] -A INPUT -i eth0 -p tcp -m tcp --dport 143 -j ACCEPT [0:0] -A INPUT -i eth0 -p tcp -m tcp --dport 993 -j ACCEPT [0:0] -A INPUT -i eth0 -p tcp -m tcp --dport 53 -j ACCEPT [0:0] -A INPUT -i eth0 -p udp -m udp --dport 25 -j ACCEPT [0:0] -A INPUT -i eth0 -p udp -m udp --dport 110 -j ACCEPT [0:0] -A INPUT -i eth0 -p udp -m udp --dport 995 -j ACCEPT [0:0] -A INPUT -i eth0 -p udp -m udp --dport 993 -j ACCEPT [0:0] -A INPUT -i eth0 -p udp -m udp --dport 53 -j ACCEPT [0:0] -A INPUT -i eth0 -p icmp -m icmp --icmp-type 0 -j ACCEPT [0:0] -A INPUT -i eth0 -p icmp -m icmp --icmp-type 3 -j ACCEPT [0:0] -A INPUT -i eth0 -p icmp -m icmp --icmp-type 11 -j ACCEPT [0:0] -A INPUT -i eth0 -p icmp -m icmp --icmp-type 11 -j ACCEPT [74:5965] -A INPUT -j block [0:0] -A FORWARD -j block [68:5458] -A block -m state --state RELATED,ESTABLISHED -j ACCEPT [6:507] -A block -i eth1 -m state --state NEW -j ACCEPT [0:0] -A block -j DROP COMMIT # Completed on Wed Feb 19 12:53:31 2003 -- Stewart Smith stewart@gammasolutions.com Programmer / UNIX Sys Admin Gamma Solutions Pty Ltd Monash Corporate Centre, Unit 11, 20 Duerdin Street, Clayton, Victoria 3168 Phone: +61 3 9562 7755 Fax: +61 3 9562 7766 Mobile: +61 4 3884 4332
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@omega) (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@delta) (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@stewart) (gcc version 2.95.4 20011002 (Debian
: prerelease)) #4 Thu Nov 28 15:06:09 EST 2002
: or
: Linux version 2.5.63 (stewart@stewart) (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@securepipe.com
_______________________________________________
LARTC mailing list / LARTC@mailman.ds9a.nl
http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
firstly, thanks for the reply.
secondly, on reading it myself, yeap - i need to clarify :)
I''ll attempt to do a diagram here (monospaced, blah blah :)
INTERNAL NETWORK INTERNET
202.44.184.130
MY PC---------------DELTA-----------------
192.168.0.18 |192.168.0.1
|
|
|
| 202.44.184.129
192.168.0.2|-------OMEGA-----------------
|
|10.0.0.2
|
|-----------ADSL ROUTER--
10.0.0.138
OMEGA has 3 NICs
eth0 = 202.44.184.129
eth1 = 192.168.0.2
eth2 = 10.0.0.2
I''ll ignore Delta as everything is working there okay atm.
I want to make sure that all connections coming into our servers (hosted
on 202.44.194.129) get serviced by that IP (that is, we send our
response via eth0 and not eth2).
>So, you want to make sure that any connections initiated from the
>Internet are always returned to the Internet via eth0, correct?
yes, that''s what we need (for things like apache to work).
I want to be able to use Masquerading on Omega. Normally a Masquerading
setup allows the internal net to access any machine out on the internet
(i use this setup at home). But, I only want to allow people on the
internal network to access one IP on the internet directly (via NAT)
that is
(as gateway using NAT)
192.168.0.18----->OMEGA-------->machine on the outside world
not
(as proxy)
192.168.0.18----->OMEGA-------->machine on outside world
what happens currently (with the scripts attached) is that a packet
comes from 192.168.0.18, goes through OMEGA and comes out on the eth2
interface (which it should, as this is the default for new connections
out) with the source address being 192.168.0.18.
what *should* happen is that a packet should go out from 192.168.0.18,
go through OMEGA (which should use NAT to change the source address to
10.0.0.2) and then it should go out on the wire (to be handled by the
ADSL router).
> 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?
The policy routing has been running for a while pretty flawlessly. The
only problem I have is that machines on the internal network can''t
access (e.g. ping) the external addresses of OMEGA.
and yes, many a cut&paste job from the HOWTO....I''m still a bit
fuzzy on
parts and how it all works... but maybe when my brain goes
''click'' i''ll
write it down so it may help others out who may be having the same
difficulty :)
i hope this has cleared some things up.
On Thu, 2003-02-27 at 11:32, Martin A. Brown wrote:> 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@omega) (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@delta) (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@stewart) (gcc version 2.95.4 20011002
(Debian
> : prerelease)) #4 Thu Nov 28 15:06:09 EST 2002
> : or
> : Linux version 2.5.63 (stewart@stewart) (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
--
Stewart Smith
stewart@gammasolutions.com
Programmer / UNIX Sys Admin
Gamma Solutions Pty Ltd
Monash Corporate Centre,
Unit 11, 20 Duerdin Street,
Clayton, Victoria 3168
Phone: +61 3 9562 7755
Fax: +61 3 9562 7766
Mobile: +61 4 3884 4332
Stewart,
: firstly, thanks for the reply.
: secondly, on reading it myself, yeap - i need to clarify :)
No problem, and thanks for the clarifications.....
: INTERNAL NETWORK INTERNET
: 202.44.184.130
: MY PC---------------DELTA-----------------
: 192.168.0.18 |192.168.0.1
: |
: |
: |
: | 202.44.184.129
: 192.168.0.2|-------OMEGA-----------------
: |
: |10.0.0.2
: |
: |-----------ADSL ROUTER--
: 10.0.0.138
:
Very clear diagram. Thank you.....
: OMEGA has 3 NICs
: eth0 = 202.44.184.129
: eth1 = 192.168.0.2
: eth2 = 10.0.0.2
: I''ll ignore Delta as everything is working there okay atm.
Fair enough....I presume, then, that you have the policy routing stuff
working properly on delta and omega, then, and you simply have a question
about omega''s masquerading (hence your subject about masquerading not
working with iproute2).
I think it''s probably an iptables solution.
: I want to make sure that all connections coming into our servers (hosted
: on 202.44.194.129) get serviced by that IP (that is, we send our
: response via eth0 and not eth2).
The million-dollar (four-part) question:
What servers hosted on 202.44.194.129?
Are these really internal servers accessed via DNAT?
Are these servers in 192.168.0.0/24?
Do these servers also wish to make use of ADSL router Internet?
If so, then you want to read the following:
http://linux-ip.net/html/adv-multi-internet.html#adv-multi-internet-inbound
http://lists.netfilter.org/pipermail/netfilter/2001-May/011697.html
Short answer? The easiest solution (if you are using DNAT on OMEGA
to get the packets to the internal server) is to dedicate an IP to be the
internal IP hosted on the server for the connection:
Internet <--> 202.44.194.129 <--OMEGA-DNAT--> 192.168.0.150 # --
two IPs
Internet <--> 10.0.0.2 <--OMEGA-SNAT--> 192.168.0.149 #
one box
Clear as mud?
If no packet from the internal server EVER needs to make it to the net via
ADSL router (''cause it''s all proxied, then the SNAT below
should solve
your problem).
: >So, you want to make sure that any connections initiated from the
: >Internet are always returned to the Internet via eth0, correct?
:
: yes, that''s what we need (for things like apache to work).
Refer to the above two links.....
: I want to be able to use Masquerading on Omega. Normally a Masquerading
: setup allows the internal net to access any machine out on the internet
: (i use this setup at home). But, I only want to allow people on the
: internal network to access one IP on the internet directly (via NAT)
:
: that is
: (as gateway using NAT)
: 192.168.0.18----->OMEGA-------->machine on the outside world
:
: not
: (as proxy)
: 192.168.0.18----->OMEGA-------->machine on outside world
:
: what happens currently (with the scripts attached) is that a packet
: comes from 192.168.0.18, goes through OMEGA and comes out on the eth2
: interface (which it should, as this is the default for new connections
: out) with the source address being 192.168.0.18.
:
: what *should* happen is that a packet should go out from 192.168.0.18,
: go through OMEGA (which should use NAT to change the source address to
: 10.0.0.2) and then it should go out on the wire (to be handled by the
: ADSL router).
Try this (I just picked an IP out of midair):
SINGLE_IP=12.8.192.113
iptables -t nat -A POSTROUTING -s 192.168.0.0/24 -d $SINGLE_IP \
-j SNAT --to-source 10.0.0.2
#
# -- or you can use "-j MASQUERADE"
#
# iptables -t nat -A POSTROUTING -s 192.168.0.0/24 -d $SINGLE_IP \
# -j MASQUERADE
#
iptables -t filter -A FORWARD -s 192.168.0.0/24 -d $SINGLE_IP \
-j ACCEPT
If I were to guess, I''d guess that the RELATED,ESTABLISHED rule should
catch the related and established connections. ;-)
: The policy routing has been running for a while pretty flawlessly. The
: only problem I have is that machines on the internal network can''t
: access (e.g. ping) the external addresses of OMEGA.
If that policy routing stuff you snipped was from DELTA, then you might
still wish to consider my changes to the P1_NET and P2_NET variables.
Your call--you can always try it and fall back to your existing and
working configuration if I''m steering you wrong.
So:
1) if you want to have the same internal host reaching the Internet,
over two connections (especially if one is inbound) dedicate an IP to
the DNAT service--it''s cheap and far less error prone.
2) Try the iptables SNAT or MASQUERADE. Don''t forget the filter table
rule in the FORWARD chain.
3) Consider correcting the network routes in your policy routing.
Good luck and so long for now,
-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/
Hi all iam trying to deploy QOS in my network i have 6MB uplink and 10MB downlink and looking to manage this nework with various kind of customers with different SLAs what kind of hardware required with out performance loss any suggestion will be appriciated what should i use to acchive different level of SLA''s looking for both ingress and egress filter and bridging too thanks hare _______________________________________________ LARTC mailing list / LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/