The problem with networking is debugging it. The worst is debugging iptables and nftables. Figuring out which chain they are going to is a massive hassle. How come we don't have any graphical tools whatsoever for this work?

[–] AnUnusualRelic@lemmy.world 8 points 17 hours ago (1 children)

There's nothing to debug, it's fucking DNS again, you know it is.

[–] Brickhead92@lemmy.world 2 points 1 hour ago

And then, even when it's not DNS, it's probably DNS.

[–] akunohana@piefed.blahaj.zone 3 points 1 day ago (1 children)

As for iptables, doesn't -j tell you where the packets are going? Or do you mean what their destination addresses and ports are? For that, on Linux, I use ss or lsof. I have never used it myself, but doesn't ufw have some GUI?

[–] onlinepersona@programming.dev 4 points 1 day ago (2 children)

Reading the iptables dump is not for beginners. Far from it. A packet can go through all tables and chains or none. And allowing a packet in one chain then begs the questions which is the next table or chain. There are maybe 100 flags and nobody can memorise them all.

Ufw just allows adding rules, ss doesn't trace packages as they go through the firewall, it can show you open ports and established connections, but it can show you which tables and chains a packet went through. lsof is even more rudimentary than ss and literally means "list open files". Since everything is a file in linux, that's a lot of files. Again, no tracing.

Somebody will say "just tcpdump". Again, no that doesn't trace which tables and chains a packet goes through. The entire firewall is a blackbox to tcpdump. At least to my knowledge. All it sees is which packets arrived and which were sent on the selected interfaces, and whether they was successful or not.

Nothing I know of traces a packet through the firewall and presents in a TUI nor GUI. I know that it's possible to make copies of packets and send then to custom chains that can log the chain and packet it came from. There might even be a way of generating a trace by adding a rule to a chain, which means adding it to every chain, but I'm not sure I've seen something do that.

[–] pishadoot@sh.itjust.works 1 points 2 hours ago (1 children)

I'm struggling to think of a situation where you'd be trying to get to that level of granularity of how a single packet is flowing end-end. Can you give an example of why you want to do that?

In all my years I've never needed to do that, which is probably pretty common, which I'd guess is why there isn't an available solution for that.

[–] onlinepersona@programming.dev 1 points 11 minutes ago

My previous response to this question.

[–] akunohana@piefed.blahaj.zone 5 points 1 day ago* (last edited 1 day ago) (1 children)

I digress. The documentation on iptables alone is an arduous read at best and requires dedication to get through and to understand. With that said, while you "cannot" (loosely said) follow any one singular packet from an iptables listing, using tcpdump will at least let you know wherefrom ~~it~~ connections originate and where they are terminating. Again, it is a hard read, not very beginner friendly, but I think it is also enough for the majority of threat models.

Question: does the person that feels that reading and understand iptables listings and tcpdumps really need to know - through an easy to read/understand UI - what chains and tables any one specific packet has traversed? What scenario/threat model/situation would that be? I'm all for discussing and widening my point of view, so don't hold back! 😊

[–] onlinepersona@programming.dev 2 points 1 day ago

Regarding your question, I've had trouble multiple times with docker (and other software) that required trying to find out just where a packet was getting stuck. The worst thing is when you open a port in the container to 0.0.0.0, send a request to it (HTTP, telnet, or otherwise) from the host via the container's IP and the packet doesn't arrive. Then you have to run through the gamut of:

are the interfaces up?
is it the IP address that's wrong?
is the the port wrong?
is the network mask correct?
is the gateway IP correct?
is the firewall somehow interfering?

There might be other things I'm missing, but once I get to the firewall stage, most of the time I just give up, put the service into a VM and try accessing it from there - if I really really care. Otherwise, I drop it and move on.

I did just find this Network address translation part 1 – packet tracing which allows tracing a packet through the firewall via xtables-monitor. It's in my notes now, so if I run into the problem again, I might have a place to start next time.

But still, that's just on my machine. Once things happen on the network and there are routers and other things involved, it's very difficult for me to debug.

[–] Saffire@sh.itjust.works 1 points 22 hours ago (1 children)

Packet Tracer?

[–] onlinepersona@programming.dev 2 points 19 hours ago (1 children)

That's a very generic name. Do you have a link?

[–] Saffire@sh.itjust.works 1 points 15 hours ago (1 children)

Sure thing, here you go:

Cisco Packet Tracer

[–] onlinepersona@programming.dev 2 points 14 hours ago (1 children)

Cisco Packet Tracer is a comprehensive networking simulation software tool for teaching and learning how to create network topologies and imitate modern computer networks.

That's for simulation. I don't think it's possible to analyse a running system to find trace packets as they go through the firewall.

Cisco Packet Tracer is available for free to all Cisco Networking Academy instructors, students, and alumni. Sign up for our free Getting Started with Cisco Packet Tracer course to learn how to download, install, and get started.

And it also requires a paid account to use.

[–] Saffire@sh.itjust.works 1 points 13 hours ago* (last edited 13 hours ago)

You simulate your exact network setup and then run testing on that. Also I was able to download a free copy to use for free for a 3 month period if you sign up for an account on that website I linked. It was fairly convoluted and a pain to get, but I was able to download and use it.