On Thu, May 02, 2002 at 07:52:02PM +0200, Johan Ihren wrote:
> On a NAT box at home I run with the following config:
> ----
> #!/usr/sbin/ipnat -v -f -
> map ep1 192.168.0.0/16 -> 213.66.164.150/32 portmap tcp/udp 40000:60000
> map ep1 192.168.0.0/16 -> 213.66.164.150/32
> map ep1 192.168.0.0/16 -> 213.66.164.150/32 proxy port ftp ftp/tcp
> 
> rdr ep1 213.66.164.150/32 port 80 -> 192.168.1.16 port 80 tcp
> ----
> I.e. I have a webserver on the inside that is publicly reachable since
> port 80 is forwarded through the firewall.
> 
> And my problem is that I cannot (from the inside) reach the webserver
> on the (forwarded) port of the public IP address. This is what I get
> from another machine on the inside:
> 
> bash# telnet 213.66.164.150 http
> Trying 213.66.164.150...
> telnet: Unable to connect to remote host: Connection refused
> 
> I'm not really surprised by this, since this is a bit on an indan rope
> trick for the poor firewall to attempt. I.e. rewrite the src of the
> packed because of the NAT, find out that dst is the firewall itself
> (which is fine), but then falling over on this particular port being
> forwarded to the inside.
> 
> So, if it isn't possible to do this I'll have to cope, but it would be
> nice if this was possible. Is it?

No it won't, unless your web server and client are on 2 different IP networks
(in which case just add another rdr line for the interface where the client
lives).
If both server and client are on the same subnet this won't work because
in a rdr the source address isn't changed. So the server will send the
reply directly (as it's on the same subnet) and as it doesn't go though
the NAT the reply won't have its header properly updated (the client
will receive a TCP packet from a IP it didn't open a connection with).

-- 
Manuel Bouyer <bouyer@antioche.eu.org>
--