Bad news: I had the exact same problem and the only solution I found was to study UDP/TCP/IP traffic & packets. That only took a few months of hard-core studying on my part...
Better news: I can give you a quick rundown.
This is an excerpt from my log. Here's what it's telling us.
Nov 11 18:24:57 daisy: [ 5287.193460] [UFW BLOCK] IN= OUT=wlan0 SRC=192.168.1.10 DST=300.120.61.72 LEN=60 TOS=0x00 PREC=0x00 TTL=64 ID=47904 DF PROTO=TCP SPT=52279 DPT=9001 WINDOW=14600 RES=0x00 SYN URGP=0
date It's good practice to watch the dates and times. If things are out of order or blocks of time are missing then an attacker probably messed with your logs.
[UFW BLOCK] indicates obviously that the packet was blocked.
IN= and OUT=wlan0 indicate whether it was incoming or outgoing. So this packet was outbound on my wlan0 connection.
SRC=192.168.1.10 This indicates the source IP, who sent the packet initially. In this case it was me. Some IPs are routable over the internet, some will only communicate over a LAN, and some will only route back to the source computer. Here's a handy guide.
DST=300.120.61.72 This indicates the destination IP, who is meant to receive the packet. (In this case it's fictitious - 255 is the highest number possible in each octet). You can use whois.net to determine who the IP belongs to (this one belongs to Swordfish ).
LEN=60 This indicates the length of the packet.
TOS and PREC These are details about the packets that aren't really relevant for reading logs. They're set to 0 which means they're not relevant in this particular packet either. More here if you care.
TTL 64 = This indicates the "Time to live" for the packet. Basically each packet will only bounce through the given number of routers before it dies and disappears. If it hasn't found its destination before the TTL expires, then the packet will evaporate. This field keeps lost packets from clogging the internet forever.
ID=47904 Not sure what this one is, but it's not really important for reading logs. It might be ufw's internal ID system, it might be the operating system's ID.
PROTO=TCP This indicates the protocol of the packet. In this case it was TCP. The other one you'll see is UDP. More explanation here.
SPT=52279 This indicates the source port. My computer generated this packet on port 52279. This is a random high port which is typical.This is a handy resource to determine what services may have started a connection. In most connections you'll see one registered port and one high unregistered one. The server typically uses the registered port & the client uses the high one. So in this instance, the source was me and it was a random high number, so I'm the client.
DPT=9001 This indicates the destination port. The receiving computer is listening on port 9001 for a connection. This is a registered port for a few different services, so the destination was the server. I run Tor so I can make a reasonable assumption that this was a Tor packet. The source & destination port will be the most important fields to understand (along with source & destination IPs) when dissecting firewall logs.
WINDOW=14600 This indicates the size of packet the sender is willing to receive.
RES=0x00 This bit is reserved for future use & is always set to 0. Basically it's irrelevant for log reading purposes.
SYN URGP=0 SYN indicates that this connection requires the three-way handshake typical of TCP connections. URGP indicates whether the urgent pointer field is relevant. 0 means it's not. Doesn't really matter for firewall log reading.
Conclusion: If I wanted to use my firewall while using Tor, then I have not set UFW up properly. I need to add a rule to allow out TCP port 9001. I hope that helps.