Hi Florian, 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. My app will either forward or respond. Currently, my app is not not even getting the first packet. I didn't have the return route but I'll add it and test it. I was trying to get packet to make it to the my app first before worrying about the return path. 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? do I need to add another rule that actually does the translation? BTW, I also have the rp_filter disabled for both the bridge interfaces 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. On Wed, Jul 10, 2019 at 1:41 AM Florian Westphal <fw@xxxxxxxxx> wrote: > > Dk Jack <dnj0496@xxxxxxxxx> wrote: > > Is my configuration correct? If so, why is my redirect rule that > > modifies the dest. port from > > 80 to 8080 not changing the port. Since my application is listening on > > 8080, could this be the > > reason my application is not seeing the traffic. > > No. TPROXY does not modify packet headers. > > > If not, what else can > > I look at to debug this > > issue? Are there any other counters I can look at (or traces that I > > can enable) to determing > > where the packets are getting lost? > > It looks like whatever problem you have is not related to netfilter. > > The TRACE messages show that packets are redirected by TPROXY as the > rule matches and packet does end up in INPUT. > > Can you check with tcpdump that a synack is sent? > If not, can you check that your bridge has the routing info needed to > reach the peer?
