[Gllug] Can't connect to apache locally

[Russell Howe]

On Mon, Oct 25, 2004 at 01:56:00PM +0100, Darren Beale wrote:
> Hi
> 
> I cannot connect to apache on localhost and I'm guessing that it's a

> links foo.url.com sits there doing nothng and a php
> fsockopen("foo.url.com","80") gives (110) Connection timed out

The question here is what IP address is the resolver returning for
foo.url.com?

> The machine has two network cards:
> 
> eth0 is the NATed interface on 10.0.3.0/24
> eth1 is the DMZ interface 10.0.2.0/24
> 
> Apache is bound to 10.0.3.131 and the VirtualHost for foo.url.com uses
> the same IP
> 
> the firewall (ipcop 1.3) green interface is 10.0.3.130 and it's
> forwarding xxx.xxx.xxx.131:80 to 10.0.3.131:80
> 
> ping foo.url.com comes back with the external IP

Aha, so it's getting the external address.

This will be likely be routed via the firewall, and I assume you are
using DNAT on the firewall to forward some port to the internal server.

What a lot of people don't seem to realise is that you should also
probably do SNAT on the firewall so that internal hosts can still use
the external address to talk to the firewall. Picture this:

Take a computer, with address 10.0.3.100, talking to the public IP
address of the webserver (let's say that's 1.1.1.1):

10.0.3.100 sends a SYN to 1.1.1.1:80 which likely goes via the default
route to the NATing firewall. The firewall performs DNAT, rewriting the
destination address to 10.0.3.131 and forwards the packet on.

The packet started something like this:

  Source address: 10.0.3.100
  Source port: x (some number)
  Destination address: 1.1.1.1
  Destination port: 80

After DNAT, it'll look something like this:

  Source address: 10.0.3.100
  Source port: x
  Destination address: 10.0.3.131
  Destination port: 80

So, this packet arrives at the web server, which goes "ooh, 10.0.3.100
wants to open a TCP connection to port 80? Well, I guess that's OK." and
the web server replies with the next stage of the TCP handshake to
10.0.3.100.

This is where the problem starts - 10.0.3.100 isn't expecting a reply
from 10.0.3.131, it's expecting a reply from 1.1.1.1 and discards the
response from 10.0.3.131 as network noise, or even an attack!

What needs to happen is that at the same time as performing DNAT, the
firewall performs SNAT to its internal address (let's say it's
10.0.3.1). This way, the packet leaves the firewall destined for
10.0.3.131, with a source address of 10.0.3.1. The web server replies to
10.0.3.1, and the firewall rewrites the source address of the packet to
be 1.1.1.1 before forwarding to 10.0.3.100.

Whew. Hope that made sense :)

The main disadvantage here is that all traffic to the web server has to
go through the firewall, even if it's from a machine on the same segment
as the web server. That could place a limit on throughput and also
increase the load on the firewall, so you may want to make foo.url.com
resolve to the internal address for hosts within your network. If you
run a bind nameserver, you can do this using zones in more recent
versions of bind.

I would still reccommend putting the SNAT rule on the firewall though -
it can be somewhat disconcerting when things that work outside the
network don't work within it...

-- 
Russell Howe       | Why be just another cog in the machine,
rhowe at siksai.co.uk | when you can be the spanner in the works?
-- 
Gllug mailing list  -  Gllug at gllug.org.uk
http://lists.gllug.org.uk/mailman/listinfo/gllug