/* HINT: Search archives @ http://www.indyramp.com/masq/ before posting! */


I fixed my problem of being able to see (and connect to) the internal web
server from the outside world. I've seen so many posts about this one
problem, I even posted one myself.  However, very little has been written
about how to solve the problem, or even steps to be taken to see what might
be going wrong. I know that my solution won't help everyone, but it might
help just one or give some people some ideas as to how to troubleshoot their
problems.

The basic idea of the setup that I had was to use the ipmasqadm port
forwarding option (portfw) to redirect requests to port 80 to an internal
web server on the local LAN network.  However, I wasn't able to connect to
the web server from the outside world.  Here are the steps that I took to
discover what was happening and solve the problem:

First, the setup of the network and my routing table, simple ipchains and
ipmasqadm scripts:

The routing table (inside interface is eth1, outside interface is eth0),
using the "route" command:

Destination     Gateway Genmask         Flags   Metric  Ref     Use
Iface
IPaddr eth1             *               255.255.255.255 UH      0       0
0       eth1
IPaddr eth0     *               255.255.255.255 UH      0       0       0
eth0
Network eth0    IPaddr eth0     255.255.255.0           UG      0       0
0       eth0
Network eth0    *               255.255.255.0           U       0       0
0       eth0
Network eth1    IPaddr eth1     255.255.255.0           UG      0       0
0       eth1
Network eth1    *               255.255.255.0           U       0       0
0       eth1
127.0.0.0       *               255.0.0.0               U       0       0
0       lo
default         IPaddr ISP      0.0.0.0                 UG      0       0
0       eth0

 ipchains and ipmasqadm script:

ipchains -F
ipchains -P forward DENY
ipchains -A forward -i eth0 -j MASQ -l 
echo "1" > /proc/sys/net/ipv4/ip_forward

ipmasqadm portfw -f
ipmasqadm portfw -a -P tcp -L <IP addr eth0> 80 -R <IP addr local web
server> 80

Now that that's out of the way, onto the steps that I took.

1) I know that these first few steps might seem redundant, but it makes sure
that the Linux box is configured for networking.  First try to ping a
machine in the outside world (I used www.yahoo.com) and see if you get a
reply back.  If not, make sure your routing table is configured correctly
and that DNS is working properly.
2) Using a computer on the inside network, with its gateway as the IP
address of eth1, and on the same subnet as eth1, try to ping first eth1,
then eth0, then a machine on the outside world (yahoo works well again).
This should all happen fine if your routing tables are configured correctly.
3) Now for the fun stuff.  Telnet or get to some external server (I telnet
into machines up at Purdue), and try to hit your web page.  If you're still
reading this, that step will probably fail.  If it does, then you need to
monitor the packets using tcpdump.  Right before you try to hit your web
page from the external server, run the command "tcpdump -i eth0 port 80 &>
output.txt".  This will cause any traffic on the eth0 interface to be
recorded in a file output.txt.  You don't need the output file, but
sometimes there is so much traffic that its hard to read it all.  Once you
have the command running, hit the web page from an external server.  Then
look at your output.txt.  There should be an entry coming from the external
server, requesting http service on your server.
4) Now to see if port forwarding is working.  Run the command "tcpdump -i
eth1 port 80 &> output.txt".  Then try to hit your web page again from an
external server.  Look at the output.txt.  If port forwarding is working,
you should see an entry from the external server going to your web server.
If you do, then everything is fine with your Linux box!  If not, then at
least you know that the problem is with port forwarding on the machine.

Those were the steps that I took to discover that I had to change the
gateway on the web server to the address of eth1.  Why is it that the
solutions to these problems are so simple?  

One last thing that I wanted to say was the two tools to use to help
diagnose the problem.  Using ipchains, log everything (using the -l option)
in a log file (stored at /var/log/messages) and look at it to see if things
are going where they should.  The other good tool to use is tcpdump.  I send
all of the output to a text file because there is so much of it, but it
helps to see where things are going once they hit the Linux box.  It also
helps to monitor each interface individually.

Let me close by saying that I know that other's problems are more complex,
and that not everything that I wrote here is 100% correct (I'm not an expert
at Linux), but I thought someone needed to write something about this
problem.  It took me four days to find out the eventual problem, and it was
frustrating to see my question asked over and over again with little or no
help on how to solve it.  

Good luck to everyone who has this problem!

"If it's not broken, don't fix it"

Bill Proudfit

Flexware Integration, Inc.
[EMAIL PROTECTED]

_______________________________________________
Masq maillist  -  [EMAIL PROTECTED]
Admin requests can be handled at http://www.indyramp.com/masq-list/ -- THIS INCLUDES 
UNSUBSCRIBING!
or email to [EMAIL PROTECTED]

PLEASE read the HOWTO and search the archives before posting.
You can start your search at http://www.indyramp.com/masq/
Please keep general linux/unix/pc/internet questions off the list.

Reply via email to