Re: Redirect bridged traffic

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



      Hello,

   I have discovered a great mechanism of understanding what is happening, but setting nftrace flag. With that I can see the dataflow:

trace id 9af9e0b6 bridge tbrFilter cbrRedirect packet: iif "eth1" ether saddr f4:8c:50:fa:1f:e5 ether daddr 00:0c:29:15:7b:a0 ip saddr 192.168.0.21 ip daddr 192.168.0.123 ip dscp 0x04 ip ecn not-ect ip ttl 64 ip id 18388 ip protocol tcp ip length 60 tcp sport 40902 tcp dport 3000 tcp flags == syn tcp window 64240 
trace id 9af9e0b6 bridge tbrFilter cbrRedirect rule log tcp dport 3000 meta pkttype set host ether daddr set 00:0c:29:15:7b:a0 counter packets 5 bytes 300 meta nftrace set 1 (verdict continue)
trace id 9af9e0b6 bridge tbrFilter cbrRedirect verdict continue 
trace id 9af9e0b6 bridge tbrFilter cbrRedirect policy accept 
trace id 9af9e0b6 inet tlcRedirect clcRedirect packet: iif "br0" ether saddr f4:8c:50:fa:1f:e5 ether daddr 00:0c:29:15:7b:a0 ip saddr 192.168.0.21 ip daddr 192.168.0.123 ip dscp 0x04 ip ecn not-ect ip ttl 64 ip id 18388 ip protocol tcp ip length 60 tcp sport 40902 tcp dport 3000 tcp flags == syn tcp window 64240 
trace id 9af9e0b6 inet tlcRedirect clcRedirect rule log tcp dport 3000 counter packets 5 bytes 300 redirect to :3000 (verdict drop)

I don't understand why the redirect rule is leading to the drop verdict.

Thank you,
Jaga.


-----Original Message-----
From: Florian Westphal <fw@xxxxxxxxx>
To: Jaga Doe <jaga.doe@xxxxxxx>
Cc: netfilter <netfilter@xxxxxxxxxxxxxxx>
Sent: Wed, Feb 5, 2020 9:35 pm
Subject: Re: Redirect bridged traffic

Jaga Doe <jaga.doe@xxxxxxx> wrote:
> table bridge tbrFilter {
>     chain cbrRedirect {
>       type filter hook prerouting priority 0;
>       log tcp dport $TPORT meta pkttype set host ether daddr set $MON_MAC counter
>     }
> }
> 
> table inet tlcRedirect {
>     chain clcRedirect {
>       type nat hook prerouting priority 0;
>       log tcp dport $TPORT counter redirect to $TPORT
>     }
> }
> 
> Using this configuration, the connection to PC0:3000 seems that it is captured by the nft but is not going to the local process.
> 
> What I am missing here?

I don't see anything wrong here, this should work and $TPORT should end
up in inet input hook.
Does it end up in forward instead or does it 'just disappear'?

Does 'nstat' show anything?




[Index of Archives]     [Linux Netfilter Development]     [Linux Kernel Networking Development]     [Netem]     [Berkeley Packet Filter]     [Linux Kernel Development]     [Advanced Routing & Traffice Control]     [Bugtraq]

  Powered by Linux