Problem in forwarding TCP packets as a NAT gateway

May 2, 2013 at 6:01 PM
Edited May 2, 2013 at 6:18 PM
First of all thank you for your great great tool :-)
I've been trying to implement a NAT gateway using pcapDotNet
I supposed we have two networks , a LAN and a WAN, we want to forward packets between LAN and WAN, with changing some headers to use a single public IP.
My program forwards udp packets successfully, but when forwarding tcp packets, some strange problems occurs. I tried to find out what is going on using wireshark.
When forwarding a tcp segment from LAN to WAN, I saw an error description in the WAN side capturing.
It says "Acknowledgement number: Broken TCP. The acknowledge field is nonzero while the ACK flag is not set"
That's the RST packet I mentioned. How can I prevent windows sending RST packet?
May 2, 2013 at 6:12 PM
I searched through other discussions and saw a similar problem. There someone said maybe the middle computer is sending RST packet, I checked my wireshark capture list and found a RST packet sent by my host.
Who is sending that packet? Is the operating system doing so? And how to prevent that?
One solution can be opening a TCP socket and listening to that port, will this help?
May 3, 2013 at 8:07 AM
Well, Windows sends a RST packet when it gets a TCP SYN packet it doesn't expect.
This makes sense - it notifies the sender that his attempt to open a TCP connection with it is not accepted.
I'm not sure how to prevent this, Googling this gave me this:
May 3, 2013 at 1:28 PM
Thank you Brickner for your answer.
I somehow figured out how to solve this problem. There is only 1 way to prevent windows from sending RST packet and that is block some RST packets using tools like WinDivert.
I chose winDivert because of its power of filtering packets in details. I change some ip layer headers (like TTL) to a specific value, before forwarding it to the wan side, and in winDivert I block every outgoing tcp RST packet which its TTL isn't that specific value. By this method, we block windows-generated RST packets and on the other hand we let the real RST packets coming from the LAN computers pass the wan side and reach its destination.
This is working for me, any other ideas will be appreciated.