tcp handshake failed.client send rst (after syn-ack). can any one advice?

Question

topology: 2 linux computer connected directly . no iptables rules (except - iptables -A OUTPUT -p tcp -j NFQUEUE ) no firewall.

route is defined as - "route add default dev eth0"

on the second one (192.168.1.1) run apache server .

I have a small program based on libnetfilter_queue that listen to the nfqueue and change the dst ip to 192.168.1.1 in case that the dst ip is 192.168.1.2 (i know that i can do it with iptables , but my program will do more things in the future), fix check sum and return to the queue.

if i call to telnet 192.168.1.1 , means that my program dosnt need to do any manipulation, handshake is OK. If i call to telnet 192.168.1.2 , my program change the dest. server get the syn and return syn-ack, but right after getting the syn-ack the client send rst.

Can anyone advice?

wireshark of the telnet

tcpdump of the telenet above

Solution 1

The reason that the client ignore the syn-ack and send rst was beacause the port tables this port was register under ip 192.168.1.2 (the original ip), so when ip 192.168.1.1 sent syn-ack back with the same port the client sent RST.

More details explain:

I have a rule on IPTABLES OUTPUT that put output packets in the nfqueue . apparently on this stage the client already allocate a port and register it with the original ip, when you change the ip this registration dosnt change.

i change the ip and return it back to the NFQUEUE with the new dest ip.

a syn is sent to the fixed ip , but when it return syn-ack back his ip is not register on this port.

So solution is to have also INPUT rule and when you get packets back from the changed ip to change the ip back to the original one.

Thank you all for your help.

Solution 2

If i call to telnet 192.168.1.2 , my program change the dest. server get the syn and return syn-ack, but right after getting the syn-ack the client send rst.

The problem you have is you're opening a TCP socket to one endpoint (192.168.1.1), rewriting the destination to 192.168.1.2 and somehow ensuring that packets are sent back to your NIC.

When those packets arrive on your NIC, you don't have an open TCP socket in the linux kernel corresponding to 192.168.1.2, so the kernel sends a RST.

The only thing you can do to stop the damage done by the RST is to insert an iptables rule to drop TCP RST packets destined to 192.168.1.2 from your source TCP port. You will need to remove this rule after you are finished.

Comments

[dkaragasidis]

Your architecture description is insufficient and vague. Please specify more details about your network. Do you have 2 network segments?

[Avihai Marchiano]

Sorry, that it was not clear from my question. My program is based on libnetfilter_queue , so i dont open any socket . i get callback when packet add to the nfqueue than i check the ip dest , change it and return it to the queue . no socket was opened (i think so).

[Mike Pennington]

Has the packet got your linux machine's IP address in it?

[Avihai Marchiano]

Yep. You can see the iptables rule in the question. I am on the output event.

[Mike Pennington]

If the SYN-ACK is addressed to the same linux machine that sends the TCP RST, then that exactly describes the situation in my answer. You can either use iptables to mangle packets, or use iptables to prevent the TCP RST from going back to the webserver

[Avihai Marchiano]

In the question there are links to wireshark and tcpdump. Dosnt the socket is opened only after the packet passed the complete stack cycle ? I can decide to drop the packets , so it's seems strange to me that socket already opened. I will try your advice.

[Avihai Marchiano]

Wow. You are great. I appreciate your help. Can you take a look on the links. To me it seems that the client ignore the server returning syn-ack.

[Avihai Marchiano]

I add a rule in the iptables to drop RST, but this is not helpfull. i still see that the client ignore the syn-ack and keep sending syn to the server. if i do the same in the same stage by iptables its work, so it have to work the same if i listen to the same state , manipulate and do accept. i cant figure out why the client igonre the syn-ack from the server. the sequence is ok, you can see in the attached link. thank you!!!!!

[Avihai Marchiano]

i run netstat in the client and i see the port that handshake try to establish register on 192.168.1.2 (the "fake" ip), so this is the reason why client send rst, but i dont understand whats wrong. I change the packet on the output stage and send it back to the queue. If i do it as a rule in iptables in the same stage (OUTPUT) it work. if i do the manipulation by the iptables i see in the netstat that the fake ip.

[Avihai Marchiano]

I tried to mangle it back by adding: iptables -A INPUT -p tcp -J NFQUEU and in my program change the source ip from 192.168.1.1 to the fake one - 192.168.1.2, but this dosnt solve the problem. if i have the following rule iptables -t nat -A OUTPUT -p tcp -d 192.168.1.2 -j DNAT --to-destination 192.168.1.1 it work without the need to mangle it back (in netstat you see that the fake one open). thank you!!!!!!

[Mike Pennington]

apologies, mindreading isnt one of my core talents. At this point you have a new question, because I dont know what your code is doing.

[Stefan]

i'd say it "should" have worked with another NFQUEUE; also this is just what DNAT does anyway, from the man page: "and all future packets in this connection will also be mangled" - this applies to packets in both directions.

[Avihai Marchiano]

its correct. i want to set it as a answer too, but you can set 2 answers. and i dont have enough budget to vote up.