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 (10.10.10.0/8), 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."
<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
Reply to: