Comment - FBXL Lotide

Comment on nftables: Can't ping my own server

nftables offers a very decent debugging interface. First, you add a rule to trace the packet (a new chain with high priority works best). Usually I’d suggest to add those rules by hand instead of relying on declarative configs:

nft add table ip ping_trace
nft 'add chain ip ping_trace prerouting { type filter hook prerouting priority -301; policy accept; }'

Then you add the actual tracing rule there with the shape to match the incoming traffic:

nft 'add rule ip ping_trace prerouting icmp type { echo-request, echo-reply } meta nftrace set 1'

now you can run nft monitor trace and see the decisions made for the matching packets. Remember to delete the ping_trace table afterwards to clean up.

original

Sort:hotnew top

confusedpuppy@lemmy.dbzer0.com ⁨1⁩ ⁨week⁩ ago

I tried what you said. I sent a ping from my computer to the server and this was the output of nft monitor trace:

trace id 1d01c81e ip ping_trace prerouting packet: iif "eth0" ether saddr b0:7d:64:e8:8f:3c ether daddr d8:3a:dd:de:28:99 ip saddr 192.168.40.201 ip daddr 192.168.40.203 ip dscp cs0 ip ecn not-ect ip ttl 64 ip id 65074 ip length 84 icmp type echo-request icmp code 0 icmp id 35586 icmp sequence 0 
trace id 1d01c81e ip ping_trace prerouting rule icmp type { echo-reply, echo-request } meta nftrace set 1 (verdict continue)
trace id 1d01c81e ip ping_trace prerouting policy accept 
trace id 1d01c81e inet filter input conntrack: ct direction original ct state new ct id 271120081 
trace id 1d01c81e inet filter input packet: iif "eth0" ether saddr b0:7d:64:e8:8f:3c ether daddr d8:3a:dd:de:28:99 ip saddr 192.168.40.201 ip daddr 192.168.40.203 ip dscp cs0 ip ecn not-ect ip ttl 64 ip id 65074 ip protocol icmp ip length 84 icmp type echo-request icmp code 0 icmp id 35586 icmp sequence 0 
trace id 1d01c81e inet filter input rule ip protocol icmp icmp type { echo-reply, destination-unreachable, echo-request, time-exceeded, parameter-problem } accept comment "Accept ICMP" (verdict accept)

I sort of get what’s happening and it looks like the ping request has been accepted.

From my computer when I send a ping it shows:

15:55 dell:/tmp/ $ ping -c1 192.168.40.203
PING 192.168.40.203 (192.168.40.203): 56 data bytes

--- 192.168.40.203 ping statistics ---
1 packets transmitted, 0 packets received, 100% packet loss

So even though it’s being accepted, I still get nothing going back to my computer, at least that’s how I understand it.

original

farcaller@fstab.sh ⁨1⁩ ⁨week⁩ ago
It is accepted just fine then. You might want to check the reverse, start in top of the output chain and trace the echo reply.

original
- confusedpuppy@lemmy.dbzer0.com ⁨1⁩ ⁨week⁩ ago
  How would trace the echo reply in the output chain? I tried adding meta nftrace set 1 directly to the ICMPv4 rule as well as making a chain postrouting rule but I can’t seem to figure it out.
  
  original
  - farcaller@fstab.sh ⁨1⁩ ⁨week⁩ ago
    I actually don’t remember off the top of my head, huh. The output chain is not the one I use often. I’d think nft add rule tracing filter output ip protocol icmp icmp type echo-reply meta nftrace set 1 would do it. Just make sure the priority is low enough again.
    
    original