Hello Grant,
thank you very much for your mail and your effort! I finally solved
the problem with exactly the commands you wrote in your mail, plus a
command for letting the firewall itself getting access to the
webserver by manipulating the NAT output chain. I found this advice on
the website http://iptables-tutorial.frozentux.net/chunkyhtml/
x4033.html - unfortunately, I found it a bit too late!
The website also addresses the problem with "manipulated logs" - but I
guess by defining a source LAN address (like you did) I can live with
this constraint...
Damn! There should be special term for this kind of stupid - yet easy
to solve problem, because I was looking and asking for about a whole
week in forums, irc channels and so on...
So, over again, thanks!
On Aug 15, 2008, at 3:12 AM, Grant Taylor wrote:
On 8/14/2008 4:17 AM, Philipp Periventas wrote:
I've got a server, running two virtual machines on it. The server
itself serves as router. I forwarded some ports, among port 80 to
one of the machines. The port forwarding works fine from the
outside (from the WAN, e.g. my computer at home) - but what doesn't
work is the access to the forwarded port 80 from INSIDE using my
external IP. That means, when I try to use lynx from my webserver,
and enter the external IP, it says connection refused.
*nod* I (loosely) refer to this a "looping through its self" type
of problem.
/Usually/ port forwarding is associated with the incoming interface
and the destination IP. So, when you have traffic coming in (to the
NATing config) from the WAN the external interface is matched
everything works fine. However when you have traffic coming in (to
the NATing config) from the LAN the external interface is not
matched and as such NATing is not done. Thus you end up with
traffic coming in to your router that is not DNATed any where and
thus coming directly in to the router which does not have any thing
listening on it.
To work around this, you will need to either not care about the
incoming interface, or handle each incoming interface
appropriately. You can not care by removing the interface portion
of your DNAT rule. However when you do this, you will DNAT any
traffic destined to your external IP over to an internal system.
The problem is that when you are DNATing internal traffic to an
internal host, the internal host will reply directly back to the
original internal client. This may seem ok, but the internal host
will reply with it's internal IP as its the source IP of the packet,
which is not what the original client is expecting.
You can get around this "TCP Triangle" (as I and others call it) by
SNATing traffic before it is DNATed to the internal host. However
I'm betting that you do not want to SNAT your external requests.
So, this is why I say handle your internal and external DNATing
separately. Have the external requests DNATed to the internal host
as they are and have your internal requests DNATed to the internal
host and SNATed to the internal IP of the NATing router. By SNATing
your internal traffic the internal host will see the traffic as
coming from the router and will reply there which will allow the
router to unDNAT the traffic and send it back to the original
internal client.
You may be able to get away using a common DNATing rule (in the
PREROUTING chain) that does not match any interfaces while using a
SNATing rule (in the POSTROUTING chain) that will SNAT any traffic
that is both from and to the internal network. This way any traffic
that comes into the router from the local LAN that is redirected
back out to the local LAN will pass back through the router on its
return trip back to the original client.
I tried to rebuild the problem with my own home linksys router, but
it worked! Then I found an option called "Filter Internet NAT
Redirection" in my linksys webinterface, and after activating that,
it didnt work any longer.
I wonder if the Linksys router is SNATing / MASQUERADing any traffic
from the LAN that is being DNATed back to the LAN. This rule would
be based on source and destination IP. If this rule is not based on
the interface, it would be trivial to spoof IPs on traffic coming in
the external interface and thus potentially be an exploit vector,
thus we would want to have the option to filter this type of
spoofing. I'm not quite sure how they came up with the name "Filter
Internet NAT Redirection", unless it means to apply the NAT rules in
such a way as they do care what interface they come in on.
Finally, I'm looking for the iptables command(s) which offer
exactly the same features as my linksys router does - permitting
LAN-clients to access LAN-services by using the EXTERNAL ip of the
router.
I don't have a way to test this at the moment, but I believe the
following two types of rules would do what you are wanting to do.
iptables -t nat -A PREROUTING -d $WAN_IP -p TCP --dport 80 -j DNAT
--to-destination $Internal_Server:80
and
iptables -t nat -A POSTROUTING -s $LAN -d $LAN -j SNAT --to-source
$LAN_IP
or
iptables -t nat -A POSTROUTING -s $LAN -d $LAN -j MASQUERADE
Has anyone an idea how to resolve this "problem"?
Again, I /think/ I understand what the problem is but I'm not 100%
positive. Also I don't currently have a way to test this. (Do to
"Life Happening" I'm currently using $hit-sco routers for my NATing
needs. Yes I'm sorry for it too.)
Thanks in advance
*nod*
You are welcome.
Grant. . . .
--
To unsubscribe from this list: send the line "unsubscribe netfilter"
in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the line "unsubscribe netfilter" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
