Dk Jack <dnj0496@xxxxxxxxx> wrote: > Thanks for taking the time. tcpdump doesn't show a syn-ack being sent. > Can you clarify on what you mean by 'routing info needed to reach the > peer'? I can see the need for routing info when the packet is going > out. However, in this case, my application is not getting the packet. accept() does not return until after 3whs has compleed, so I am not sure wha you mean by this. > btw, you mentioned "No. TPROXY does not modify packet headers." > if that's true, then how will the ip stack deliver the packet to my > application which is listening on port 8080? TPROXY associates the initial packets with the listening socket, not the IP stack. After 3whs has completed, a socket that matches the tuples in use will exist and ip stack can work normally. Your itpables TRACE logs show that mangle prerouting, first rule, is matching/accpeting the packet, so that part works. Your TRACE log also shows that the packet has been diverted to INPUT and makes it through filter/nat hooks. So, AFAICS, from nefilter pov. all appears to be ok. > do I need to add another rule that actually does the translation? No. > and ip_forward is enabled. Do you have any pointers on how to go about > debugging the issue if its getting dropped beyond net-filter? Any > pointers is greatly appreciated. You could check nstat, if that shows no clue you could have a look at perf, specifically "script net_dropmonior".
