LinuxQuestions.org - IPtables redirect 127.0.0.1 to 192.168.1.113

- Linux - Networking (https://www.linuxquestions.org/questions/linux-networking-3/)

- - IPtables redirect 127.0.0.1 to 192.168.1.113 (https://www.linuxquestions.org/questions/linux-networking-3/iptables-redirect-127-0-0-1-to-192-168-1-113-a-818817/)

IPtables redirect 127.0.0.1 to 192.168.1.113

Hi to the forums wizards!

On my Debian 5 system, I'm trying to redirect the TCP traffic directed towards the 127.0.0.1:5432 address (local PostgreSQL daemon) to the 192.168.1.113:5432 (LAN PostgreSQL server).

Any idea on how to achieve this result with iptables?

I *THINK* this is what you are looking for - unfortunately I am unable to test the below but -i specifies what interface is being matched for the rule... so any connections on the lo interface that are tcp and destined for port 5432 will be nat'd to 192.168.1.113 port 5432

Try it and see how you go.

/sbin/iptables -t nat -I PREROUTING -i lo -p tcp --dport 5432 -j DNAT --to-destination 192.168.1.113

You cannot redirect loopback traffic with iptables.

Quote:

Originally Posted by 2HeartLinuxIs2BGeek (Post 4028039)

Thanks for the answer, but I already have tried that solution and it doesn't work.

The problem is on the localhost traffic.

Quote:

Originally Posted by SuperJediWombat! (Post 4028065)

You cannot redirect loopback traffic with iptables.

This is the answer I came after a day of testing and ircing on the #Netfilter and #debian channel.

These are the workarounds I came:

Code:

ssh localhost -L ${local_port}:${remote_host}:${remote_port}

# or

ssh ${user}@${remote_host} -L ${local_port}:localhost:${remote_port}

# or

ssh localhost -L ${local_port}:${remote_host}:${remote_port} sleep 10; 

${local_command_using_tunnel}

# or

socat TCP4-LISTEN:${local_port} TCP4:${remote_host}:${remote_port}

Everyone has a workaround, but no one is able to explain me why it is not possible with iptables to redirect the localhost traffic.

For example, -j REDIRECT works redirecting the port for the local traffic; why it is not possible with iptables to redirect the localhost traffic?

references:
http://lists.debian.org/debian-user/.../msg00542.html
http://lists.debian.org/debian-itali.../msg00148.html
http://lists.debian.org/debian-itali.../msg00170.html

Quote:

Originally Posted by SuperJediWombat! (Post 3993370)

The PREROUTING chain is only for traffic coming into the netfilter system.
Localy generated traffic goes to OUTPUT rather than PREROUTING.

However, loopback traffic (127.0.0.0/8) skips both chains...

In short, you can not DNAT loopback traffic.

http://www.linuxquestions.org/questi...arding-812313/

I was thinking about your problem, permanent solution would be to use xinetd and the redirect option.

Quote:

Originally Posted by nickname.random (Post 4028413)

For example, -j REDIRECT works redirecting the port for the local traffic; why it is not possible with iptables to redirect the localhost traffic?

Code:

REDIRECT target



The REDIRECT target is used to redirect packets and streams to the machine itself. This means that we could

for example REDIRECT all packets destined for the HTTP ports to an HTTP proxy like squid, on our own host.

Locally generated packets are mapped to the 127.0.0.1 address. In other words, this rewrites the destination

address to our own host for packets that are forwarded, or something alike.

The REDIRECT target is extremely good to use when we want, for example, transparent proxying,

where the LAN hosts do not know about the proxy at all. 



Note that the REDIRECT target is only valid within the PREROUTING and OUTPUT chains of the nat table.

It is also valid within user-defined chains that are only called from those chains, and nowhere else.

The REDIRECT target takes only one option, as described below. 



Table 11-13. REDIRECT target options

Option:          --to-ports

Example:  iptables -t nat -A PREROUTING -p tcp --dport 80 -j REDIRECT --to-ports 8080



Explanation:        

The --to-ports option specifies the destination port, or port range, to use.

Without the --to-ports option, the destination port is never altered. This is specified, as above, --to-ports 8080

in case we only want to specify one port. If we would want to specify a port range, we would do it like

--to-ports 8080-8090, which tells the REDIRECT target to redirect the packets to the ports 8080 through 8090.

Note that this option is only available in rules specifying the TCP or UDP protocol with the --protocol matcher,

since it wouldn't make any sense anywhere else.

As you can see REDIRECT doesn't change the destination IP.

The best solution is to find how to enforce application to send packets to the LAN, instead of local server.

I tested the xinetd settings for you, this should work.

Code:

service postgresql

{

        socket_type            = stream

        wait                    = no

        user                    = root

        redirect                = 192.168.1.113 5432

        bind                    = 127.0.0.1

}

Quote:

Originally Posted by nimnull22 (Post 4028995)

Code:

In other words, this rewrites the destination address to our own host for packets that are forwarded

As you can see REDIRECT doesn't change the destination IP.

We were talking about using iptables to *redirect* traffic, this would apply to either the DNAT target or the REDIRECT target. Your answer is not really helpful and worse, it will confuse people.

Quote:

Originally Posted by nimnull22 (Post 4028995)

As you can see REDIRECT doesn't change the destination IP.

Yes, I already know that REDIRECT can't change the IP address but only the port.
I was trying to understand what's the technical and undocumented reason because it is not possible to do the same think for the loopback traffic.

Quote:

The best solution is to find how to enforce application to send packets to the LAN, instead of local server.

Of course, but if you can't modify the application, the only solution is a workaround with a third part application like:
ssh, netcat, socat
or as suggested by SuperJediWombat!, using xinetd.

Quote:

Originally Posted by SuperJediWombat! (Post 4028983)

I was thinking about your problem, permanent solution would be to use xinetd and the redirect option.

That's a nice and elegant idea. Good job!

Quote:

Originally Posted by SuperJediWombat! (Post 4028983)

Code:

service postgresql

{

        socket_type            = stream

        wait                    = no

        user                    = root

        redirect                = 192.168.1.113 5432

        bind                    = 127.0.0.1

}

It should work very well. I'll try and I'll give you a feedback.

Thanks!

xnetd works like a charm! ;)

Simply fantastic. Thanks SuperJediWombat!