Re: problem reach the internal.

[Joel Newkirk <netfilter@newkirk.us>]

On Friday 29 November 2002 08:35 pm, Anders Fugmann wrote:
> james.Q.L wrote:
> > sorry, i forgot mention that the request from outside my local network to
> > the INET_IP:8888 is fine. only the internal request to it fails.
> >
> > i do not see what is wrong in the rules, anyone ?
>
> It cannot be done, as the webserver will try to give an answer to the
> query directly, and not back through your router, and thus the client
> will not accept the reply.
>
> For a more complete explanation, search the email archives. This
> question has been asked and answered numerous times.

That's what his SNAT rule should handle: (snippet from original message)

> the rules i added to try to make it work are :
> 
> iptables -t nat -A PREROUTING -p tcp -i eth1 --dport 8888 \
>       -j DNAT --to-destination 192.168.0.3:80
> iptables -A FORWARD -p tcp --dport 80 -d 192.168.0.3 -j ACCEPT
> iptables -t nat -A POSTROUTING -p tcp -s 192.168.0.0/24 -d 192.168.0.3 \
>     --dport 80 -j SNAT --to-source 192.168.0.1

port 80 requests heading out to the server (192.168.0.3) from anywhere on the 
lan (already DNATted in prerouting) are SNATted to appear to come from the 
firewall/router (192.168.0.1) so that they return through it properly.  Yes, 
this has been answered before, and is covered in the DNAT section of Oscar's 
tutorial, but the rules he has here appear to be correct. (well, along with 
the FORWARD EST/REL rule I didn't include in this snippet)

James - I'd recommend that you try:
iptables -z
to clear counters, then try accessing the server from the LAN, then
iptables -L -v -n
to list your ruleset along with the packet/byte counts which matched.  This 
will often show where unexpected things are happening.  IE, if the counts in 
the FORWARD rules accepting ESTABLISHED/RELATED and packets destined for the 
server are both zero, then the problem is at PREROUTING.  If the FORWARD 
count for server-bound shows your request, but your POSTROUTING SNAT is zero, 
or if those both show counts but nothing coming back from the server 
(EST/REL) those can narrow things down.  (of course if the DNAT rule in 
PREROUTING counts 0 that pretty much nails the problem down... :^) Extreme 
Logging can help as well, where you insert a LOG rule as the first rule in 
each chain, try to connect, then check the logs.  This can generate a LOT of 
logging if there is other activity through the firewall, though.  If you do 
this, you should log nat PRE and POST, FORWARD, and INPUT.  The first three 
are where it should be, the fourth is where it shouldn't but might, if the 
DNAT isn't matching.

I'd also suggest you reconsider FORWARD rule #2, which accepts EVERYTHING, and 
limit your MASQUERADE to traffic outbound to the internet, simply with 
-o $eth0 or whatever interface connects to the world.

j