NetFilter
[Top] [All Lists]

Re: Connect to localhost bound port from outside?

To: Mail List - Netfilter <netfilter@lists.netfilter.org>
Subject: Re: Connect to localhost bound port from outside?
From: Pascal Hambourg <pascal.mail@plouf.fr.eu.org>
Date: Wed, 31 Jan 2007 17:03:42 +0100
Delivered-to: sp-com-lists@consult.net
Delivered-to: netfilter-list1@securepoint.com
In-reply-to: <45C0B772.2090201@riverviewtech.net>
List-archive: </pipermail/netfilter>
List-help: <mailto:netfilter-request@lists.netfilter.org?subject=help>
List-id: General discussion and user questions <netfilter.lists.netfilter.org>
List-post: <mailto:netfilter@lists.netfilter.org>
List-subscribe: <https://lists.netfilter.org/mailman/listinfo/netfilter>, <mailto:netfilter-request@lists.netfilter.org?subject=subscribe>
List-unsubscribe: <https://lists.netfilter.org/mailman/listinfo/netfilter>, <mailto:netfilter-request@lists.netfilter.org?subject=unsubscribe>
Organization: Plouf !
References: <eppgne$mc1$1@sea.gmane.org> <45C06BE7.2080208@plouf.fr.eu.org> <45C0B772.2090201@riverviewtech.net>
Sender: netfilter-bounces@lists.netfilter.org
User-agent: Mozilla Thunderbird 1.0.6 (Windows/20050716)
Grant Taylor a écrit :
Pascal Hambourg wrote:

Iptables will happily redirect anything you like to localhost, but the kernel IP routing prohibits communications with a loopback address on a non loopback interface and thus will drop the packets.

Does this apply if the reverse path filter is turned off?

Yes. This is not a reverse path issue, as rp_filter=1 checks only the source address, not the destination address.

Or is this a hard coded filter in the kernel that can not be gotten around?

AFAIK, it is hard coded. I guess the reason is that RFC 3330 reserves 127.0.0./8 for the loopback and prohibits its use on any network outside the host. Unfortunately, the routing code does not know that the packet was DNATed and has an original non-loopback destination address.

Another thought to the OP would be to use the Dummy interface in lieu of the Loop Back interface as I believe it does not have the same restrictions that Loop Back does. However I could be mistaken.

I do not see how a dummy interface might be useful here. Can you please clarify ?

I have often considered using lo for local only but using dummy as a spur network to bind services to and then route traffic in to the spur network. Thoughts / Opinions?

A dummy interface is a black hole, a kind of "/dev/null" interface, traffic you route to it is lost. This is very different from a loopback interface, whose traffic you route to it loops back and is received by the local host. It is fine to use a dummy interface if you want to add an extra address to the host and bind services to it, but I guess you could do the same with the loopback interface.


<Prev in Thread] Current Thread [Next in Thread>