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
