Hi Gabriele,
if I get this right - this could be your solution. Cory Petkovsek described
it on 05/09/2001 here on list. I´ve cited his mail:
On Wed, May 09, 2001 at 11:02:07AM -0300, Jeronimo Pellegrini wrote:
masquerading and port forwarding (we want connections
to ports 25 and 80 forwarded to our mail and web server,
besides some other things).
It mostly works as it is now, except for one problem:
From the outside world, everything works perfectly,
and ports are forwarded:
[EMAIL PROTECTED]:~$ telnet xxx.xxx.xxx.xxx 80
Trying xxx.xxx.xxx.xxx...
Connected to xxx.xxx.xxx.xxx.
Escape character is '^]'.
Yes this is connected (see connected to...)
from the internal network (10.10.10.0/8), it seems
that ports are being forwarded, but after the connection
is established, nothing else happens:
[EMAIL PROTECTED]:~$ telnet firewall 80
Trying xxx.xxx.xxx.xxx...
This did not connect. This is shows your packets went unsanswered (or the
answer wasn't recognized. read on). You have not received any thing coming
back, such as a reject packet. On any non-firewall computer try telnet
localhost 10 or some other port that is closed. You won't see trying
You will see trying .: connection refused. This means you got
a packet back saying we are closed.
snip
I think the problem is that your workstation on a 10.x.x.x connects to the
firewall, which NATs the packet and reroutes it to a webserver on a 10.x.x.x
network. Unfortunately for you, the workstation and the webserver are on the
same network.
Juno = 10.120
webserver = 10.107
firewall = 10.101
juno: connect to firewall (10.120 -- 10.101)
firewall: dnat to www (10.120 -- 10.107)
juno: waiting for a packet back from firewall --over
www: response packets (10.107 -- 10.120)
juno: what are these packets from www?!? I'm dropping them
juno: waiting for a packet back from firewall --over
The problem is that www is not routing the packets back from whence they
came, thus allowing the firewall to un-DNAT them. The webserver sees
packets coming from juno for itself, so it responds to them directly. You
have spoofed your own packets, and have faked out your own servers. ;)
Possible solutions?
- Put your servers on a different subnet so that all traffic to the server
must be routed through your firewall (probably not a good idea for
performance).
- What you need is to both DNAT and SNAT a packet, but I don't know if you
can do both at once.
Sorry, I don't have an answer for how to fix it, but perhaps this will spark
someone else's comment.
Cory
