Funky hardware firewall problem...

[Robin Battey]

Greg:

I recently ran into this problem.  Here's what *my* problem was, may or may not be yours ...

When you're accessing the server from outside the firewall, the NAT works just dandy.  Of course.  But
when you're behind it, here's what can happen: Packet from local machine (we'll use the example network,
192.0.2.0/24, for the outside and a standard RFC1918 network 10.0.0.0/8 for the inside), which we'll
call 10.0.0.2, sends to the outside ip address, which we'll call 192.0.2.1 (we'll use 10.0.0.1 as the
internal ip address of the firewall). This outside ip address then gets NAT'ed to point to the internal
web server (back to itself).  This would give us the following problem:

  client sends SYN:           source 10.0.0.2 dest 192.0.2.1
  firewall changes dest:      dest from 192.0.2.1 to 10.0.0.2

  webserver recieves SYN:     source 10.0.0.2 dest 10.0.0.2
  webserver sends SYN/ACK:    source 10.0.0.2 dest 10.0.0.2
  (firewall not touched)

  client receives SYN/ACK:    source 10.0.0.2 dest 10.0.0.2
  (webserver can't find an established connection for this packet, so it drops it)

  (original connection eventually times out)

As you can see, the NAT'ing fscks up the connection, because the webserver is expecting a packet with
the original addresses it sent in the SYN packet -- and they never come.  This is different than from
outside the firewall, because from outside the firewall, the *return* packets also get NAT'ed (because
they have to go through the firewall to get back).  On the local network, the return packets never touch
the firewall, and therefore don't get NAT'ed.

Now, with a linux box, you can set it up so that *all* traffic gets masqueraded, no matter what
interface it comes in on or goes out on.  This would cause the packe from the local machine to have both
it's destination *and* source addresses changed -- basically, the firewall claims the connection as its
own.  Here's what happens:

  client sends SYN:           source 10.0.0.2 dest 192.0.2.1
  firewall changes dest:      from 192.0.2.1 to 10.0.0.2 (port forwarding)
  firewall changes source:    from 10.0.0.2 to 10.0.0.1 (ip masquerading)

  webserver recieves SYN:     source 10.0.0.1 dest 10.0.0.2
  webserver sends SYN/ACK:    source 10.0.0.2 dest 10.0.0.1

  firewall changes source:    from 10.0.0.2 to 192.0.2.1 (reverse mapping of ip masquerading)
  firewall changes dest:      from 10.0.0.1 to 10.0.0.2  (reverse mapping of port forwarding)

  client recieves SYN/ACK:    source 192.0.2.1 dest 10.0.0.2
  (this matches, and the connection proceeds along happily)

This is actually *usually* a misconfiguration.  Most people don't want their routers to NAT internal
traffic, because that puts a load on the router that isn't necessary.

This sounds like the problem you're having from ghandi, but I don't know why the mac box would work
unless it was on a different subnet (because then it would go through the router).

Hope this helps.  Cheers!
-robin

On Mon, Jan 27, 2003 at 10:26:54AM -0800, Greg Stark wrote:
> So after years of faithful service from my Redhat firewall NAT box, i'v 
> decided to go with a much more *slient* hardware router made by belkin 
> (really cheap!)...
> 
> After installing this new hardware router, I'm discovering that I 
> cannot access any servers from behind my firewall by using the internet 
> hostname (a problem my linux router never had). basically, i have a 
> web-server accessible from the outside world called 
> 'ghandi.homelinux.org'.  From the actual linux machine that this 
> web-server runs on, i now have to use 'localhost' instead of 
> http://ghandi.homelinux.org
> 
> The connection just seems to time out?  The funny thing is that can go 
> over to my Mac which is also behind the firewall and access 
> 'ghandi.homelinux.org' just fine...
> 
> Does anyone have any idea what my problem is??? (Other than the 
> obvious!)
> 
> - Greg
> gdstark at mac.com

-- 
                        Robin Battey

     90CF 2E8F 8A96 D0C0 09A2  9CFE C130 6CD4 6DC3 6DCF
              http://www.zanfur.com/zanfur.pub
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 230 bytes
Desc: not available
Url : http://mailman1.u.washington.edu/pipermail/linux/attachments/20030127/40dc57c0/attachment.bin