From: Boyd Stephen Smith Jr. on 9 Jul 2010 16:40 On Friday 09 July 2010 10:06:23 Daniele Orlando wrote: > On Fri, Jul 9, 2010 at 08:34, Boyd Stephen Smith Jr. > <bss(a)iguanasuicide.net> wrote: > > What have you tried? It seems like you'd need to change this in a > > PREROUTING chain, probably in the mangle table. > > I have tried any configuration of PREROUTING, POSTROUTING, OUTPUT over > nat table. > I have not tried the mangle table, but I know it is used to change the > packet headers, > and I think that is not our case. One of the packet headers is the destination IP, which you are changing. The mangle table might be appropriate here. Since you want that change to affect which interface is used for sending the packet, it must occur in PREROUTING. That said, I would not be surprised if there is special handling for 127/8 on lo* devices. -- Boyd Stephen Smith Jr. ,= ,-_-. =. bss(a)iguanasuicide.net ((_/)o o(\_)) ICQ: 514984 YM/AIM: DaTwinkDaddy `-'(. .)`-' http://iguanasuicide.net/ \_/
From: Javier Barroso on 10 Jul 2010 07:10 On Fri, Jul 9, 2010 at 5:54 AM, Daniele Orlando <d.orlando.0(a)gmail.com>wrote: > Hello guys, > > on my Debian 5 I'm trying to redirect > the TCP traffic generated by my machine > towards 127.0.0.1:5432 (PostgreSQL) > to the new destination 192.168.1.113:5432. > > I have tried with iptables many rules, but no one seams good for the task. > > Any idea? > Hi, If you have ssh access to 192.168.1.113, you can try ssh port forwarding, with -L 5432:192.168.1.113:5432 option Regards,
From: Mart Frauenlob on 10 Jul 2010 13:10 On 09.07.2010 05:54, Daniele Orlando wrote: > Hello guys, > > on my Debian 5 I'm trying to redirect > the TCP traffic generated by my machine > towards 127.0.0.1:5432 (PostgreSQL) > to the new destination 192.168.1.113:5432. > > I have tried with iptables many rules, but no one seams good for the task. > > Any idea? > > This picture shows the netfilter traffic flow: http://jengelh.medozas.de/images/nf-packet-flow.png Source address selection is done before the OUTPUT path. Locally generated packets NEVER hit the PREROUTING chain in mangle or nat table. There is a routing decision after the mangle table OUTPUT chain. But you cannot do address translation there (like in nat OUTPUT). What you can do, is MARK packets in the mangle table, and refer to this mark with iproute2 (ip rule add fwmark 0x1 lookup table custom_table) - this is called "policy based routing". So from looking at the picture and from the theory I know, theoretically something like this could work: echo "101 custom_table" >> /etc/iproute2/rt_tables fill the table with appropriate routes: ip route add table custom_table ... .... mark in mangle table: iptables -t mangle -A OUTPUT -d 127.0.0.1 -p tcp --dport 5432 -j MARK --set-mark 0x1 dnat in nat table: iptables -t nat -A OUTPUT -m mark --mark 0x1 -j DNAT --to-destination 192.168.1.113 snat in nat table: iptables -t nat -A POSTROUTING -m mark --mark 0x1 -j SNAT --to-source 192.168.1.1? add iproute rule: ip rule add fwmark 0x1 lookup custom_table I've done all this for testing and I did not succeed. I also did: echo 0 >/proc/sys/net/ipv4/conf/all/rp_filter not sure if that interacts. I then put a trace rule: iptables -t raw -A OUTPUT -d 127.0.0.1 -p tcp --dport 5432 -j TRACE The resulting log always ended in the nat table's OUTPUT chain. I don't know why acutally, from the picture (which is from a developer) it should hit nat POSTROUTING. I'm telling you this, so you could eventually try and maybe you have more luck than me, or maybe the information is otherwise useful. However maybe it's not possible, I can't tell for sure. I would have done some ssh tunneling myself in the first place. But I know there are people at the netfilter mailing list, who do know for sure. It's in general the best place to ask netfilter related questions. Best regards Mart -- To UNSUBSCRIBE, email to debian-user-REQUEST(a)lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmaster(a)lists.debian.org Archive: http://lists.debian.org/4C38A736.7030007(a)chello.at
From: Daniele Orlando on 11 Jul 2010 13:50 On Sat, Jul 10, 2010 at 13:06, Javier Barroso <javibarroso(a)gmail.com> wrote: > Hi, If you have ssh access to 192.168.1.113, you can try ssh port > forwarding, with -L 5432:192.168.1.113:5432 option > > Regards, Hi Javier, thanks for the tip. Your solution is one of the possible workarounds we came. Another one (I'm using it) can be done with "socat": socat TCP4-LISTEN:${local_port},fork,reuseaddr TCP4:${remote_host}:${remote_port} Credits to the guys of #Netfilter and #debian channels. Thanks Javier. References: http://lists.debian.org/debian-italian/2010/07/msg00148.html http://lists.debian.org/debian-italian/2010/07/msg00170.html http://www.linuxquestions.org/questions/showthread.php?p=4027927 freenode.#Netfilter #debian -- To UNSUBSCRIBE, email to debian-user-REQUEST(a)lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmaster(a)lists.debian.org Archive: http://lists.debian.org/AANLkTinsKr6Fw_Md8O3v8Meaqtbty-_fFKwlp43Rd2vL(a)mail.gmail.com
From: Daniele Orlando on 11 Jul 2010 19:10
On Sat, Jul 10, 2010 at 19:00, Mart Frauenlob <mart.frauenlob(a)chello.at> wrote: > This picture shows the netfilter traffic flow: > http://jengelh.medozas.de/images/nf-packet-flow.png > > Source address selection is done before the OUTPUT path. > Locally generated packets NEVER hit the PREROUTING chain in mangle or nat > table. > There is a routing decision after the mangle table OUTPUT chain. > But you cannot do address translation there (like in nat OUTPUT). > What you can do, is MARK packets in the mangle table, and refer to this mark > with iproute2 (ip rule add fwmark 0x1 lookup table custom_table) - this is > called "policy based routing". > > > So from looking at the picture and from the theory I know, theoretically > something like this could work: > > echo "101 custom_table" >> /etc/iproute2/rt_tables > > fill the table with appropriate routes: > ip route add table custom_table ... > ... > > mark in mangle table: > iptables -t mangle -A OUTPUT -d 127.0.0.1 -p tcp --dport 5432 -j MARK > --set-mark 0x1 > > dnat in nat table: > iptables -t nat -A OUTPUT -m mark --mark 0x1 -j DNAT --to-destination > 192.168.1.113 > > snat in nat table: > iptables -t nat -A POSTROUTING -m mark --mark 0x1 -j SNAT --to-source > 192.168.1.1? > > add iproute rule: > ip rule add fwmark 0x1 lookup custom_table > > > I've done all this for testing and I did not succeed. > I also did: > echo 0 >/proc/sys/net/ipv4/conf/all/rp_filter > not sure if that interacts. > I then put a trace rule: > iptables -t raw -A OUTPUT -d 127.0.0.1 -p tcp --dport 5432 -j TRACE > > The resulting log always ended in the nat table's OUTPUT chain. > I don't know why acutally, from the picture (which is from a developer) it > should hit nat POSTROUTING. > I'm telling you this, so you could eventually try and maybe you have more > luck than me, or maybe the information is otherwise useful. > However maybe it's not possible, I can't tell for sure. > I would have done some ssh tunneling myself in the first place. > But I know there are people at the netfilter mailing list, who do know for > sure. It's in general the best place to ask netfilter related questions. > > Best regards > > Mart Thanks Mart, your experiment will not be lost. At the moment I have not a lot of time to spend extending your work, but it is a good starting point for further enhancement. As you are suggesting, I'll integrate it with the infos coming from the netfilter mailing list and #Netfilter irc channel. At the moment, the good news is that, together with the ssh, netcat, and socat animals, we have a new friend: xinetd service postgresql { socket_type = stream wait = no user = root redirect = 192.168.1.113 5432 bind = 127.0.0.1 } Thanks again for the time spent answering me. Daniele p.s.: The xinetd tip comes from SuperJediWombat! of linuxquestions.org. http://www.linuxquestions.org/questions/linux-networking-3/iptables-redirect-127-0-0-1-to-192-168-1-113-a-818817/ -- To UNSUBSCRIBE, email to debian-user-REQUEST(a)lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmaster(a)lists.debian.org Archive: http://lists.debian.org/AANLkTila28GqHmpb75bm18KCi-H7UFNG0eR53LG9J-YS(a)mail.gmail.com |