lan users surfing on lan webserver

lan users surfing on lan webserver

[Magnus Solvang]

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

Re: lan users surfing on lan webserver

[Magnus Solvang]

Quoting Magnus Solvang (magnus@solvang.net):
| 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

Problem with string

[hare ram]

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

Re: Problem with string (remove References-line in mailhead)

[Magnus Solvang]

Quoting hare ram (hareram@sol.net.in):
| 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: <20030225215326.GA30804@first.knowledge.no> \
<20030227123531.GA26259@first.knowledge.no>

- M

Re: Problem with string (remove References-line in mailhead)

[Joel Newkirk]

On Thursday 27 February 2003 08:48 am, Magnus Solvang wrote:
> Quoting hare ram (hareram@sol.net.in):
> | 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: <20030225215326.GA30804@first.knowledge.no> \
> <20030227123531.GA26259@first.knowledge.no>
>
> - 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

Re: Problem with string (remove References-line in mailhead)

[Magnus Solvang]

Quoting Joel Newkirk (netfilter@newkirk.us):
| On Thursday 27 February 2003 08:48 am, Magnus Solvang wrote:
| > Quoting hare ram (hareram@sol.net.in):
| > | 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

Re: Problem with string

[Raymond Leach]

On Thu, 2003-02-27 at 15:51, hare ram wrote:
> 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.
Did you recompile the iptable 127a sourcecode?

> ---
> 
> 
> when i check with modprob its accepting the module
> 
> what could be the problem
> 
> thanks
> hare
-- 

Re: lan users surfing on lan webserver

[Magnus Solvang]

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

Re: lan users surfing on lan webserver

[Joel Newkirk]

On Monday 03 March 2003 08:37 am, Magnus Solvang wrote:

> I have moved a webserver behind my iptables-firewall.

> 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 have this relevant FORWARD chain:
> $IPTABLES -A INPUT -i $EXTIF -m state --state NEW,ESTABLISHED,RELATED
> \ -p tcp -d $EXTWEBSERVER1 --dport 80 -j ACCEPT

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.

> 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.

j

Re: lan users surfing on lan webserver

[Magnus Solvang]

Quoting Joel Newkirk (netfilter@newkirk.us):
[...]
| 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