Hi Florian, I added a default route out like you suggested to the bridge interface and it did not help. On Wed, Jul 10, 2019 at 12:01 PM Dk Jack <dnj0496@xxxxxxxxx> wrote: > > 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?
