[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: [long] NAT & port forwarding iptables problem

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:
> jeronimo@pinheiros:~$ 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 (, it seems
> that ports are being forwarded, but after the connection
> is established, nothing else happens:
> jeronimo@juno:~$ 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."  


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.


Reply to: