[LARTC] masquerading not working with iproute2?

[LARTC] masquerading not working with iproute2?

[Stewart Smith]

[-- Attachment #1: Type: text/plain, Size: 5600 bytes --]

(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

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [LARTC] masquerading not working with iproute2?

[Martin A. Brown]

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 2.44.184.129
 : IP2\x10.0.0.2
 :
 : P1 2.44.184.134
 : P2\x10.0.0.138

All reasonable....

 : P1_NET 2.44.184.135
 : P2_NET\x10.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 2.44.184.128/29
P2_NET\x10.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/

Re: [LARTC] masquerading not working with iproute2?

[Stewart Smith]

[-- Attachment #1: Type: text/plain, Size: 9355 bytes --]

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

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [LARTC] masquerading not working with iproute2?

[Martin A. Brown]

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\x12.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/