3 way masquerade

I have a redhat 6.1 machine that currently does NAT using IPCHAINS and IP Masquerade between two networks. It is the gateway for the internal network

eth0 (internal net)    netmask
eth1 (external net) netmask

I need to add a ADSL connection so the internal network can access the internet and would like to do so by adding another NIC to this machine. I will be using a single fixed IP address.

eth2 (the internet) 2x4.25x.2xx.x  netmask

I have all three NIC's up and running. Looking aroung the web all the examples for 3 way systems I find are based on the DMZ concept which is not what I am looking for. I want the internal network (eth0)to be able to access both the external network (eth1) and the internet (eth2) primarily for http and mail. I DON'T want any unsolicited stuff coming into the internal network from either eth1 or eth2. I also don't want the external net (eth1) to be able to access the internet (eth2) or to be subjected to unsolicited stuff from the internet (eth2)

Who is Participating?
I wear a lot of hats...

"The solutions and answers provided on Experts Exchange have been extremely helpful to me over the last few years. I wear a lot of hats - Developer, Database Administrator, Help Desk, etc., so I know a lot of things but not a lot about one thing. Experts Exchange gives me answers from people who do know a lot about one thing, in a easy to use platform." -Todd S.

lewisgAuthor Commented:
Edited text of question.
lewisgAuthor Commented:
Edited text of question.
Let's start with routing:

route add default netmask eth2
route add -net netmask eth0
route add -net netmask eth1

Check to be sure you don't have any extraneous routes that are in conflict with the 3 shown above.

Now we move on to masquerading, but only for the internal network:

/sbin/ipchains -A forward -i eth2 -s -d -j MASQ

Regarding your desire to filter "unsolicited stuff", I suggest you identify the port numbers you want to protect.  For example, let's say you want to block port 80 (http) access from the external net to the internal net, in which case you could try this:

/sbin/ipchains -A forward -s -d 80 -j DENY

You should be able to modify this command to block access to whatever ports you want to protect on either the internal or external network, assuming this Linux box is the sole router between the two.  Where you see port 80, you can specify a range of ports in X:Y format.  

I suggest adding all of this stuff to a custom script file that you call yourself out of /etc/rc.d/rc.local.  Mine is /etc/rc.d/rc.localnet
When you upgrade, it's a one-liner to replace the call in /etc/rc.d/rc.local.

Cloud Class® Course: Microsoft Exchange Server

The MCTS: Microsoft Exchange Server 2010 certification validates your skills in supporting the maintenance and administration of the Exchange servers in an enterprise environment. Learn everything you need to know with this course.

Did it work?
lewisgAuthor Commented:
Sorry I have not been more prompt on this question... Other stuff got to be "more important".

When I enter:
route add default netmask eth2
I get back a nasty:
Usage: inet_route [-vF] del {-host|-net} Target[/prefix] [gw Gw] [metric M] [[de
v] If]
       inet_route [-vF] add {-host|-net} Target[/prefix] [gw Gw] [metric M]
                              [netmask N] [mss Mss] [window W] [irtt I]
                              [mod] [dyn] [reinstate] [[dev] If]
       inet_route [-vF] add {-host|-net} Target[/prefix] [metric M] reject
       inet_route [-FC] flush      NOT supported                      

Is this command attempting to add a route for all packets not covered in the next two "route add -net" statements? If so would this be more appropriate?

route add default gw 2x4.25x.2xx.1 eth2

where 2x4.25x.2xx.1 is the ISP's default gateway.

I screwed up!  It should be:

route add default eth2

Having  "default" and "" was redundant (not to mention erroneous), having "netmask" is optional.

Specifying the gateway "gw x.x.x.x" is also optional.   If you were to include it, the command would be:

route add default gw x.x.x.x eth2

Where x.x.x.x is your ISP gateway.

Experts Exchange Solution brought to you by

Your issues matter to us.

Facing a tech roadblock? Get the help and guidance you need from experienced professionals who care. Ask your question anytime, anywhere, with no hassle.

Start your 7-day free trial
lewisgAuthor Commented:
Thanks for the help! I think I finally got it. The "route add default eth2" appears to be the only one needed since the others routes appear to already exist.

After much study I came up with the following for IPCHAINS. If you see a problem please let me know.

#      rc.firewall for xxxxxxx 2/18/0

echo "1" > /proc/sys/net/ipv4/ip_forward

/sbin/ipchains -F input
/sbin/ipchains -P input REJECT
/sbin/ipchains -F output
/sbin/ipchains -P output ACCEPT
/sbin/ipchains -F forward
/sbin/ipchains -P forward REJECT

/sbin/ipchains -M -S 7200 10 60

/sbin/ipchains -A input -s -i lo -j ACCEPT
/sbin/ipchains -A input -s -i eth0 -j ACCEPT

/sbin/ipchains -A input -s -p 1 -j ACCEPT
/sbin/ipchains -A input -s -i eth1 -j DENY
/sbin/ipchains -A input -s -i eth2 -j DENY

/sbin/ipchains -A input -s -d 1024:5999 -i eth1 -p 6 -j ACCEPT
/sbin/ipchains -A input -s -d 6002:65535 -i eth1 -p 6 -j ACCEPT
/sbin/ipchains -A input -s -d 1024:65535 -i eth1 -p 17 -j ACCEPT
/sbin/ipchains -A input -s -d 53:53 -i eth1 -p 6 -j ACCEPT
/sbin/ipchains -A input -s -d 53:53 -i eth1 -p 17 -j ACCEPT
/sbin/ipchains -A input -s -d 25:25 -i eth1 -p 6 -j ACCEPT

/sbin/ipchains -A input -s -d 1024:5999 -i eth2 -p 6 -j ACCEPT
/sbin/ipchains -A input -s -d 6002:65535 -i eth2 -p 6 -j ACCEPT
/sbin/ipchains -A input -s -d 1024:65535 -i eth2 -p 17 -j ACCEPT
/sbin/ipchains -A input -s -d 53:53 -i eth2 -p 6 -j ACCEPT
/sbin/ipchains -A input -s -d 53:53 -i eth2 -p 17 -j ACCEPT
/sbin/ipchains -A input -s -d 25:25 -i eth2 -p 6 -j ACCEPT

/sbin/ipchains -A forward -s -j MASQ

Those rules look good to me; no obvious problems. Of course, the real test is how it works in action.  

If you are interested, there is a product called cheops, which you can get from www.rpmfind.net or www.marko.net .  This program will map an entire subnet for you.   You can also browse the MIB of any SNMP-managable stuff you might have (including Linux boxes with SNMP enabled).  

One of the provisions of the program is to do a port scan, which would help test your filters.  You could set this up on a crappy little 486 box, and use it on either of your networks to try a portscan on your masquerading box (or any valid IP address, for that matter).
lewisgAuthor Commented:
Did the install today. Everything went well until I hit a machine that does Point to Point Tunneling Protocol. It would connect then time out on verifying username and password. I checked with tech support at the origin of the tunnel and they speculated that the problem was most likely my firewall not passing PPTP packets. I checked the /etc/protocols file and can find no reference to PPTP.

What do you think...
Which network has the PPTP machine?  

I think it's purely a routing issue.  If Linux is trying access networks that are connected via the PPTP machine, then you need a route to the remote PPTP network with a gateway that specifies the ethernet address of the PPTP machine (which needs to be in one of the subnets that Linux is directly connected to).

To really pursue the issue, I need to know what IP addresses the PPTP machine has for it's ethernet address and the interface address of the ppp interface as well as the network address of the PPTP remote network, along with the display of the routing table.  If you can produce all that, I can tell you what has to happen to make it all work.

I have a Linux box that makes a PPTP connection to an NT server at my office.  I had to masquerade the PPTP network because the hosts on the remote network did not have a route to return packets to my private network.  By masquerading, I made it look like all the activity came from the ppp interface on the Linux box (that was in the same subnet as the remote PPTP network, after all.  
lewisgAuthor Commented:
The problem is that a machine on the  internal net (eth0 172.20.1.x) cannot connect to a PPTP server(?) across the Internet (eth3 -> ADSL). This application is web browser on an internal machine accessing remote confidential records via the Internet.

I don't have all the numbers available right now. However there are no ppp interfaces involved. I am a little confused...
OK, that explains a little more.  The PPTP connection doesn't work because the internal machine does not have a "real" IP address.  Because it's connection to the Internet is masqueraded, all outgoing packets have the address of eth2.

PPTP does not masquerade very well, but then again, it doesn't really have to.

Depending on how you feel about security in general, you <could> have the Linux box make the PPTP connection to this PPTP server, and then add a static route to the network that becomes reachable via PPTP.  The Linux box is everyone's default gateway anyway, so static routes on that machine will allow anyone to reach the remote PPTP network.  You can use Ipchains to tighten the forwarding so that only the right machine can reach the PPTP network.  Let me know if you want more information on setting this up.

One question I would ask: Is the remote PPTP server the same machine (web server) that you need to reach?  Or is it acting as a router to enable access to a network that includes the web server in question?  The configuration is a little easier if the PPTP server is also the web server.

There is probably a way to make this work with ipmasqadm and autofw, but my experience is with using the Linux box to handle all of the tricky stuff that works better with a "real" IP address and leaving the masquerading to the common IP applications (web,pop3,ftp,telnet,etc.)
lewisgAuthor Commented:
I think the remote PPTP server is also the webserver. It is no big deal if everyone on the internal network can reach the PPTP server. The remote PPTP server appears to have a static IP. I think I already tried the obvious:

/sbin/ipchains -A input -s -i eth2 -j ACCEPT
(where is the IP of the PPTP server)

I read somewhere that PPTP uses TCP on port 1723 and IP on port 47. However neither of these appear in /etc/services. Is that a problem.

The internal network is all W95 and private IP's

Thanks for all of your help with this. You are a wizard!
To make this work with Linux, you would first set up the /etc/ppp/chap-secrets file.  If the PPTP server is going to authenticate you as username "BCLINTON" and password "funwithmonica" then the file would look like this:

# Secrets for authentication using CHAP
# client  server  secret  IP addresses
BCLINTON      *   funwithmonica

Next, you need PPTP CLIENT software for Linux, available at http://www.moretonbay.com/vpn/pptp.html This site is a great source of VPN information.  I learned a great deal from it.

In this example, I have a local private network that is, My PPTP server is at w.x.y.z and offers a route to the network.  The script (run as root) looks like this:

/sbin/ifconfig ppp0 down
/sbin/route del -net
rm -rf /var/run/pptp/*
/usr/bin/pptp w.x.y.z name BCLINTON debug netmask
sleep 5
/sbin/route add -net netmask ppp0
ipchains -A forward -i ppp0 -s -d -j MASQ

If anything unusual happens, the results will be somewhere in /var/log, according to whatever you have specified in /etc/syslog.conf (try /var/log/messages).

Following my example, the script runs and makes the PPTP connection.  At that point, my entire local network can connect anywhere on the private network.  

Notice the use of IP masquerade on the ipchains forwarding to the PPTP network.  Those IP addresses on the remote PPTP network have no routing information that would get packets delivered back to the private network that originated them, hence the need for masquerade.  This way, it looks like all this activity originates from an address that is ppp0 (which picks up an address in the PPTP network's subnet, so routing is not a problem).  

Other people may have ideas on allowing the PPTP traffic to be originated on the private network and forwarded  via  Linux.  You might want to post that as a new question if you want to explore the concept.
It's more than this solution.Get answers and train to solve all your tech problems - anytime, anywhere.Try it for free Edge Out The Competitionfor your dream job with proven skills and certifications.Get started today Stand Outas the employee with proven skills.Start learning today for free Move Your Career Forwardwith certification training in the latest technologies.Start your trial today
Linux Networking

From novice to tech pro — start learning today.