lan users surfing on lan webserver

I'm configuring a firewall on a network where we have put the webserver on the inside of the firewall and given it a reserved ip-address.
I have done the appropriate forwarding so that the webserver can be reached from the internett. Trouble is, users on the LAN have to use its internal ip-address to reach the web- pages. I know I can set up an internal dns-server to fix this, but I was hoping it would be possible to solve this with some more ip-forwarding.

Is it possible to forward internal requests going to the external webserver-address back into it's internal address?

Is it recommended? :)

I have found one example of this behaviour vie google, but it doesn't work.

- M

Quoting Magnus Solvang ([email protected]):

| I'm configuring a firewall on a network where we have put
| the webserver on the inside of the firewall and given it
| a reserved ip-address.
| I have done the appropriate forwarding so that the webserver
| can be reached from the internett. Trouble is, users on the
| LAN have to use its internal ip-address to reach the web-
| pages.

I've been reading the docs, but still haven't figured this one out.

According to NAT-HOWTO-10.html, I've set up these rules:

$IPTABLES -t nat -A PREROUTING -i $EXTIF -d $EXTWEBSERVER1 -p tcp \
--dport 80 -j DNAT --to $INTWEBSERVER1
$IPTABLES -t nat -A POSTROUTING -d $INTWEBSERVER1 -s $INTNET -p tcp \
--dport 80 -j SNAT --to 192.168.1.20

192.168.1.20 is the internal ip-address on the firewall.

The first line is working fine (I can reach the server from the internet).
But, the second line isn't doing what I hoped it would - the users on the LAN cannot use the outside URL to get to the internal webserver. tcpdump shows traffic going from the internal client -> external webserver-address and back, but nothing reaches the interal webserver.

I noticed that the OUTPUT chain logged dropped packages from the internal client to the webserver, and this rule cleared that up:

$IPTABLES -A OUTPUT -p tcp -o $INTIF -s $EXTWEBSERVER1 \
--sport 80 -d $INTNET -j ACCEPT

But now, no packets are logged, and it's still not working. I'm guessing the POSTROUTING line need an appropriate FORWARD-rule... If so, what would it look like?

- M

Hi all
i have redhat 8.0 and upgraded to latest kernel
with the following information
Linux inca 2.4.18-24.8.0custom #4 Thu Feb 27 14:14:50 IST 2003 i686 i686 i386 GNU/Linux

and patched with string and iptable 1.2.7a

when i try to excute the command

[root@inca extra]# iptables -I INPUT -m string --string 'cmd.exe' -j QUEUE iptables v1.2.7a: Couldn't load match `string':/usr/local/lib/iptables/libipt_string.so: cannot open shared object
file: No such file or directory

Try `iptables -h' or 'iptables --help' for more information.
---

when i check with modprob its accepting the module

what could be the problem

thanks
hare

Quoting hare ram ([email protected]):
| Hi all

Please remove the "References"-line in the mailheader when replying to someone elses mail while changing the topic.

This new thread is sorted under a thread I started now (lan users surfing on lan webserver), and I first thought it was an answer to my question(s).

You should have removed this line (my linebreak):

References: <[email protected]> \
<[email protected]>

- M

Not a particularly helpful suggestion, as most people do not manually edit headers, nor even have the ability to do so. Not with most email client software, and certainly not with Outlook Express, which was used to send the message you complain about. Mutt and OE are worlds apart.

More helpful would be to suggest NOT using "reply" and then changing the subject, since that is VERY likely how that field ended up in the header of his message.

j

Quoting Joel Newkirk ([email protected]):

| On Thursday 27 February 2003 08:48 am, Magnus Solvang wrote:
| > Quoting hare ram ([email protected]):
| > | Hi all
| >
| > Please remove the "References"-line in the mailheader when
| > replying to someone elses mail while changing the topic.
[...]
| Not a particularly helpful suggestion
[...]
| More helpful would be to suggest NOT using "reply" and then changing the 
| subject, since that is VERY likely how that field ended up in the header 
| of his message.

I believe that was implied in my response to Ram. This is a technical mailinglist. If someone can't edit the headers, then don't reply to someone elses mail when starting a new thread.

- M

Did you recompile the iptable 127a sourcecode?

I'm trying this one one more time, since I still haven't found a solution.
I have moved a webserver behind my iptables-firewall. Outside dns for this webserver still points to its external ip-address, so I've set up the firewall to listen to this ip-address (ethx-alias), and forward the traffic to the internal webserver using DNAT. This works.
However, the clients on the LAN cannot use the external URL to surf to this machine, they have to use its internal ip-address (I know I could set up Bind on the inside, but I'm trying to avoid this). I'm using the solutions suggested in the NAT-Howto:

http://www.netfilter.org/documentation/HOWTO//NAT-HOWTO-10.html

but the traffic is not reaching the internal webserver.

Using tcp-dump, I see that when the client tries to connect to

http://$external_url/

it connects to the ethX-alias on the firewall (the webservers old ip-address), and thus gets a "Connection refused", since the firewall isn't running a webserver - it's only supposed to forward the traffic bound for this ip-address to the internal webserver. But the forwarding is not working when initiated from the LAN.

I have this relevant FORWARD chain:
$IPTABLES -A INPUT -i $EXTIF -m state --state NEW,ESTABLISHED,RELATED \
-p tcp -d $EXTWEBSERVER1 --dport 80 -j ACCEPT

PREROUTING:
$IPTABLES -t nat -A PREROUTING -i $EXTIF -d $EXTWEBSERVER1 -p tcp \
--dport 80 -j DNAT --to $INTWEBSERVER1

POSTROUTING (http://www.netfilter.org/documentation/HOWTO//NAT-HOWTO-10.html)

$IPTABLES -t nat -A POSTROUTING -d $INTWEBSERVER1 -s $INTRANET -p tcp \
--dport 80 -j SNAT --to-source 192.168.1.20

192.168.1.20 being the firewalls LAN-address...

- M

FORWARD or INPUT? It should be:

$IPTABLES -A FORWARD -p tcp -d $INTWEBSERVER1 --dport 80 -m state --state NEW,ESTABLISHED,RELATED -j ACCEPT

FORWARD because after DNAT has done its job this traffic is no longer addressed to the firewall box. $INTWEBSERVER1 for the same reason. And skip the "-i $EXTIF" to ensure it matches connections from the LAN as well as 'outside' clients.

Again, you might want to drop the "-i $EXTIF" part...

This part looks fine as-is.

j

Quoting Joel Newkirk ([email protected]):
[...]

| It should be:
| 
| $IPTABLES -A FORWARD -p tcp -d $INTWEBSERVER1 --dport 80
| -m state --state NEW,ESTABLISHED,RELATED -j ACCEPT

Yes, I quoted the wrong part. Sorry about that. I had the line you mention in my script.

| FORWARD because after DNAT has done its job this traffic is no longer | addressed to the firewall box. $INTWEBSERVER1 for the same reason.

Yes...:

| And 
| skip the "-i $EXTIF" to ensure it matches connections from the LAN as 
| well as 'outside' clients.

Doh!!! :)

There I have for copying a line that would forward connections from the internet to an internal webserver, and leaving it like that when trying to forward traffic from the internal net as well. So obvious (now).

| > PREROUTING:
| > $IPTABLES -t nat -A PREROUTING -i $EXTIF -d $EXTWEBSERVER1 -p tcp \
| > --dport 80 -j DNAT --to $INTWEBSERVER1
| 
| Again, you might want to drop the "-i $EXTIF" part...

:)

| > $IPTABLES -t nat -A POSTROUTING -d $INTWEBSERVER1 -s $INTRANET -p tcp
| > \ --dport 80 -j SNAT --to-source 192.168.1.20
| 
| This part looks fine as-is.

And now the rest looks fine too. Thank you, Joel for seeing what I couldn't! :)

And thanks to Pavan Gokarn, for helping me to debug my script!

- M