Iptables and portforwarding to an internal webserver.

[Ken Bradford]

> -----Original Message-----
> From: colug-bounces at colug.net [mailto:colug-bounces at colug.net]On Behalf
> Of Rob Funk
> Sent: Wednesday, June 09, 2004 1:47 PM
> To: COLUG
> Subject: Re: Iptables and portforwarding to an internal webserver.
>
>
> Ken Bradford wrote:
> > I've run into a snag forwarding ports 80 & 443 to an internal webserver
> > for a client. I _thought_ everything was fine. I could access their
> > webserver from my office just fine, but it turns out they can't access
> > it internally by going to the public address.
>
> At my old company we called this the "in-out-in" or "IOI"
> problem, because
> the inside is trying to go out and then back in.  I think we
> ended up with
> some userland daemon hack to fix it, which I never liked.  On the other
> hand, I wasn't in the room for the conversations that spawned the name or
> the solution.  (Also, at the time we were using OpenBSD, not Linux.)
>
> I think the easiest solution is to fix it in DNS, so that the
> internal DNS
> server returns internal addresses for public names.  Using my
> domain as an
> example, you might set it up so that the outside gets 65.118.13.43 when
> they look up www.funknet.net, but the inside gets 192.168.20.5 when they
> look up the www.funknet.net.
>

I think you might be right.

>
> It looks like you tried to add rules saying "rewrite TCP packets destined
> for any internal machine's web ports so they go to the web server."  This
> wouldn't do any good since your problem is with packets destined for the
> external address, not the internal address.  However, you already had
> rules rewriting packets destined for the external address.

Yes, that makes sense.

>
> I think the solution may lie in changing some drop rules you didn't show
> us.  You need your FORWARD chain (and OUTPUT chain) to allow packets from
> $INNET to $INNET.

Yes, that would seem necessary. It didn't solve the problem, but would seem
necessary.

>
> Also try adding some log rules matching the internal and external address
> of the web server.

Yes, very usefull indeed. Tcpdump too.

It appears that the problem is a simple "what is sent and what is expected"
one. When my PC sends packets accross the internet to their firewall address
(which are then redirected to the webserver) it expects packets back from
the firewall. When "George" sends packets across his LAN to the firewall
(which are then redirected to the webserver) they arrive at the webserver as
coming from "George", not the firewall, so return packets are sent to
"George", not the firewall. Meanwhile, "George" is expecting packets from
the firewall. He didn't request anything from the webserver, so he doesn't
want them.

Ken Bradford
Alpha II Service, Inc.