Why is it impossible to DNAT 127.0.0.0/8?

Why is it impossible to DNAT 127.0.0.0/8?

[Quentin, Lars]

Hey,

For the last few days I tried to DNAT a port on localhost to a local VM living inside a virtual bridge network.
I got it working using the external IP with a OUTPUT rule in the NAT table, as it can't be done via PREROUTING:
`iptables -t nat -A OUTPUT -p tcp --dport 8080 -d <MY_IP> -j DNAT --to-destination 192.168.1.2:80`
which allows me to `curl <MY_IP>:8080`.

I'd expect that it `curl localhost:8080` would work with something like this:
`iptables -t nat -A OUTPUT -p tcp -o lo --dport 8080 -d localhost -j DNAT --to-destination 192.168.1.2:80`
but this just results in packages getting stuck.

After reading a lot I found [1] which tries to define it as a feature to conform the RFCs 5735/1700/1812.
Is this really the only reason or is it technically impossible due to sth like the limitations of `lo` since it is not a real device?
I feel way to much of a novice to navigate the kernel source.

Cheers
Lars Quentin

[1]: https://serverfault.com/questions/363899/iptables-dnat-from-loopback

Re: Why is it impossible to DNAT 127.0.0.0/8?

[Paul Robert Marino]

hey everyone,
i just realized the list has been rejecting my answers to this chain
because i didn't send them in plain text so below are my two responses
so everyone can see them

It's a kernel security restriction that was added in the 2.4 kernel to
prevent a large number of issues that can happen when you route
connections to a loopback interface. it blocks all traffic from any
subnet attached to any loopback interface from being routable by
adding it to the "Martian IP" list
https://en.wikipedia.org/wiki/Martian_packet#:~:text=A%20Martian%20packet%20is%20an,Assigned%20Numbers%20Authority%20(IANA).
The full explanation for this is long but it has to do with a large
number of security vulnerabilities that were quite common on Linux and
Unix in the 1990's and early 2000's many of which were never fixed but
were mitigated by this change. Essentially the reason they chose to
mitigate it instead of fixing it is it involves thousands of
applications which falsely assume that the loopback interface is
secure so they use it for unauthenticated IPC. Programmers still
commonly make this mistake so it is an extremely risky security
feature to disable.

Instead you should use a "dummy" interface with a routable IP if you
want to bind a service to a virtual interface that does not go down if
a physical interface does. see
https://developers.redhat.com/blog/2018/10/22/introduction-to-linux-interfaces-for-virtual-networking/
  https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/8/html/configuring_and_managing_networking/creating-a-dummy-interface_configuring-and-managing-networking
or https://itectec.com/ubuntu/ubuntu-ubuntu-18-04-how-to-create-a-persistent-dumthe-network-interface/
for details on how to set one up.
You will also need to modify the configuration of the service to bind
to the dummy interface.

The other option is to modify the services configuration to bind to a
physical interface, IP address, or 0.0.0.0 (All interfaces)



hey Lars,
I realized that my response may have not been as helpful as i would
have liked so i read through your poset on segfault and i have a more
tailored answer for you
it looks like from what you said this is exactly the kind of unsecured
IPC connection the kernel developers were worried about in the first
place, that said there were additional options developed for your
situation.
What I recommend is using stunnel instead of DNAT.
you can configure Stunnel to listen on both the source and target
machines and wrap your connection in a pseudo VPN SSL tunnel
the kernel will allow this and it should be transparent to your application.
Now this is not the standard use case for stunnel but it is one of the
original use cases in the design the key configuration parameter that
you need to pay attention to is "client". on the source side client
must be set to "yes" and on the target side client must be set to "no"
see https://docs.opnsense.org/manual/how-tos/stunnel.html for a rough
example of how this is done and for the full documentation for stunnel
see chttps://www.stunnel.org/docs.html
you may also want to consider pairing it with xinetd to launch the
tunnels as needed in order to reduce risk of the tunnel breaking and
support for the host.allow and hosts.deny acls via tcpwrappers as an
additional security measure.


On Wed, Apr 28, 2021 at 5:52 PM Paul Robert Marino <prmarino1@gmail.com> wrote:
>
> hey Lars,
> I realized that my response may have not been as helpful as i would have liked so i read through your poset on segfault and i have a more tailored answer for you
> it looks like from what you said this is exactly the kind of unsecured IPC connection the kernel developers were worried about in the first place, that said there were additional options developed for your situation.
> what i recommend is using stunnel instead of DNAT.
> you can configure Stunnel to listen on both the source and target machines and wrap your connection a pseudo VPN SSL tunnel
> the kernel will allow this and it should be transparent to your application.
> now this is not the standard use case for stunnel but it is one of the original use cases in the design the key configuration parameter that you need to pay attention to is "client". on the source side client must be set to "yes" and on the target side client must be set to "no"
> see https://docs.opnsense.org/manual/how-tos/stunnel.html for a rough example of how this is done and for the full documentation for stunnel see chttps://www.stunnel.org/docs.html
> you may also want to consider pairing it with xinetd to launch the tunnels as needed in order to reduce risk of the tunnel breaking and support for the host.allow and hosts.deny acls via tcpwrappers as an additional security measure.
>
>
>