0

I'm having a hard time getting my head around this ufw issue I'm having.

Here is the output of ufw status verbose:

Status: active    
Logging: on (low)    
Default: deny (incoming), allow (outgoing), disabled (routed)    
New profiles: skip    

To                         Action      From    
--                         ------      ----    
5666                       ALLOW IN    141.0.32.124    
5666                       ALLOW IN    141.0.32.125    
5666                       ALLOW IN    5.153.254.130    
5666                       ALLOW IN    5.153.255.250    
5666                       ALLOW IN    5.153.255.251    
5666                       ALLOW IN    5.153.255.252    
5666                       ALLOW IN    78.31.107.85    
5666                       ALLOW IN    89.200.136.31    
5666                       ALLOW IN    89.200.136.76    
40                         ALLOW IN    86.30.129.70    
40                         ALLOW IN    89.200.136.76    
40                         ALLOW IN    Anywhere    
80                         ALLOW IN    Anywhere    
993                        ALLOW IN    Anywhere    
25                         ALLOW IN    Anywhere    
443                        ALLOW IN    Anywhere    
60000:60010/udp            ALLOW IN    Anywhere    
48850                      ALLOW IN    Anywhere    
40 (v6)                    ALLOW IN    Anywhere (v6)    
80 (v6)                    ALLOW IN    Anywhere (v6)    
993 (v6)                   ALLOW IN    Anywhere (v6)    
25 (v6)                    ALLOW IN    Anywhere (v6)    
443 (v6)                   ALLOW IN    Anywhere (v6)    
60000:60010/udp (v6)       ALLOW IN    Anywhere (v6)    
48850 (v6)                 ALLOW IN    Anywhere (v6)

Ports 80 and 443 are clearly open to all connecting clients, however, according to the ufw logfile, around an hour after reloading the firewall, legitimate requests are being denied (this includes access to the other 'open' ports, with the exception of port 40 - currently running ssh, the reason for which I am also unsure).

There was a similar case with this question, though the fact that there were many requests indicates either a browser retrying the connection or the user reloading before giving up.

Here's a sample from the ufw logfile. The hostname, mac address, source IP and destination IP have all been hidden, but were all identical and matched what I was expecting.

Aug  9 16:16:20 server_hostname kernel: [UFW BLOCK] IN=eth0 OUT= MAC=my_mac SRC=src_ip DST=my_ip LEN=48 TOS=0x00 PREC=0x00 TTL=110 ID=13107 DF PROTO=TCP SPT=59353 DPT=22 WINDOW=8192 RES=0x00 SYN URGP=0            
Aug  9 16:16:26 server_hostname kernel: [UFW BLOCK] IN=eth0 OUT= MAC=my_mac SRC=src_ip DST=my_ip LEN=48 TOS=0x00 PREC=0x00 TTL=110 ID=14035 DF PROTO=TCP SPT=59353 DPT=22 WINDOW=8192 RES=0x00 SYN URGP=0        
Aug  9 16:16:29 server_hostname kernel: [UFW BLOCK] IN=eth0 OUT= MAC=my_mac SRC=src_ip DST=my_ip LEN=48 TOS=0x00 PREC=0x00 TTL=110 ID=14730 DF PROTO=TCP SPT=59764 DPT=22 WINDOW=8192 RES=0x00 SYN URGP=0        
Aug  9 16:16:32 server_hostname kernel: [UFW BLOCK] IN=eth0 OUT= MAC=my_mac SRC=src_ip DST=my_ip LEN=48 TOS=0x00 PREC=0x00 TTL=110 ID=15403 DF PROTO=TCP SPT=59764 DPT=22 WINDOW=8192 RES=0x00 SYN URGP=0        
Aug  9 16:16:36 server_hostname kernel: [UFW BLOCK] IN=eth0 OUT= MAC=my_mac SRC=src_ip DST=my_ip LEN=48 TOS=0x00 PREC=0x00 TTL=110 ID=16002 DF PROTO=TCP SPT=60080 DPT=22 WINDOW=8192 RES=0x00 SYN URGP=0        
Aug  9 16:16:38 server_hostname kernel: [UFW BLOCK] IN=eth0 OUT= MAC=my_mac SRC=src_ip DST=my_ip LEN=48 TOS=0x00 PREC=0x00 TTL=110 ID=16401 DF PROTO=TCP SPT=59764 DPT=22 WINDOW=8192 RES=0x00 SYN URGP=0        
Aug  9 16:16:39 server_hostname kernel: [UFW BLOCK] IN=eth0 OUT= MAC=my_mac SRC=src_ip DST=my_ip LEN=48 TOS=0x00 PREC=0x00 TTL=110 ID=16673 DF PROTO=TCP SPT=60080 DPT=22 WINDOW=8192 RES=0x00 SYN URGP=0        
Aug  9 16:16:43 server_hostname kernel: [UFW BLOCK] IN=eth0 OUT= MAC=my_mac SRC=src_ip DST=my_ip LEN=48 TOS=0x00 PREC=0x00 TTL=110 ID=17426 DF PROTO=TCP SPT=60525 DPT=22 WINDOW=8192 RES=0x00 SYN URGP=0        
Aug  9 16:16:45 server_hostname kernel: [UFW BLOCK] IN=eth0 OUT= MAC=my_mac SRC=src_ip DST=my_ip LEN=48 TOS=0x00 PREC=0x00 TTL=110 ID=17758 DF PROTO=TCP SPT=60080 DPT=22 WINDOW=8192 RES=0x00 SYN URGP=0        
Aug  9 16:16:46 server_hostname kernel: [UFW BLOCK] IN=eth0 OUT= MAC=my_mac SRC=src_ip DST=my_ip LEN=48 TOS=0x00 PREC=0x00 TTL=110 ID=17959 DF PROTO=TCP SPT=60525 DPT=22 WINDOW=8192 RES=0x00 SYN URGP=0        
Aug  9 16:17:07 server_hostname kernel: [UFW BLOCK] IN=eth0 OUT= MAC=my_mac SRC=src_ip DST=my_ip LEN=48 TOS=0x00 PREC=0x00 TTL=110 ID=20735 DF PROTO=TCP SPT=61082 DPT=22 WINDOW=8192 RES=0x00 SYN URGP=0        
Aug  9 16:17:17 server_hostname kernel: [UFW BLOCK] IN=eth0 OUT= MAC=my_mac SRC=src_ip DST=my_ip LEN=48 TOS=0x00 PREC=0x00 TTL=110 ID=22576 DF PROTO=TCP SPT=61245 DPT=22 WINDOW=8192 RES=0x00 SYN URGP=0        
Aug  9 16:17:37 server_hostname kernel: [UFW BLOCK] IN=eth0 OUT= MAC=my_mac SRC=src_ip DST=my_ip LEN=48 TOS=0x00 PREC=0x00 TTL=110 ID=24621 DF PROTO=TCP SPT=62083 DPT=22 WINDOW=8192 RES=0x00 SYN URGP=0        
Aug  9 16:18:00 server_hostname kernel: [UFW BLOCK] IN=eth0 OUT= MAC=my_mac SRC=src_ip DST=my_ip LEN=48 TOS=0x00 PREC=0x00 TTL=110 ID=30227 DF PROTO=TCP SPT=63235 DPT=22 WINDOW=8192 RES=0x00 SYN URGP=0        
Aug  9 16:18:17 server_hostname kernel: [UFW BLOCK] IN=eth0 OUT= MAC=my_mac SRC=src_ip DST=my_ip LEN=48 TOS=0x00 PREC=0x00 TTL=110 ID=32393 DF PROTO=TCP SPT=63714 DPT=22 WINDOW=8192 RES=0x00 SYN URGP=0        
Aug  9 16:18:46 server_hostname kernel: [UFW BLOCK] IN=eth0 OUT= MAC=my_mac SRC=src_ip DST=my_ip LEN=48 TOS=0x00 PREC=0x00 TTL=110 ID=4219 DF PROTO=TCP SPT=64631 DPT=22 WINDOW=8192 RES=0x00 SYN URGP=0        
Aug  9 16:19:02 server_hostname kernel: [UFW BLOCK] IN=eth0 OUT= MAC=my_mac SRC=src_ip DST=my_ip LEN=48 TOS=0x00 PREC=0x00 TTL=110 ID=6636 DF PROTO=TCP SPT=64938 DPT=22 WINDOW=8192 RES=0x00 SYN URGP=0        
Aug  9 16:19:31 server_hostname kernel: [UFW BLOCK] IN=eth0 OUT= MAC=my_mac SRC=src_ip DST=my_ip LEN=48 TOS=0x00 PREC=0x00 TTL=110 ID=11548 DF PROTO=TCP SPT=49493 DPT=22 WINDOW=8192 RES=0x00 SYN URGP=0        
Aug  9 16:19:40 server_hostname kernel: [UFW BLOCK] IN=eth0 OUT= MAC=my_mac SRC=src_ip DST=my_ip LEN=48 TOS=0x00 PREC=0x00 TTL=110 ID=13669 DF PROTO=TCP SPT=49493 DPT=22 WINDOW=8192 RES=0x00 SYN URGP=0        
Aug  9 16:19:58 server_hostname kernel: [UFW BLOCK] IN=eth0 OUT= MAC=my_mac SRC=src_ip DST=my_ip LEN=48 TOS=0x00 PREC=0x00 TTL=110 ID=16165 DF PROTO=TCP SPT=50228 DPT=22 WINDOW=8192 RES=0x00 SYN URGP=0

There are no records matching this timestamp in the webserver log files, and neither was I expecting any, the firewall blocked the connection.

At this moment in time, running ufw reload works (the firewall behaves as expected, allowing connections on those ports), and I'm currently holding the fort with a job in cron.hourly to reload the firewall using said command. (I'm not using service ufw reload in the job, as a failure on restart would mean that the firewall would not be active, and it could be hours or even days before I can even find out about it, let alone resolve it - I'm on holiday, and entertaining myself with watching a vietnamese telecoms company try to break into port 22, which is closed).

Nobody else seems to be having this problem, despite searching for it over the last week.

The real question I'm trying to ask, for those who want a clear question, is how do I allow connections to the open ports on the firewall without them all being blocked by the firewall until a reload?

Any help would be much appreciated!

3
  • Is that ufw status output from a time when the problem was happening? Are all clients blocked or just some? Aug 10, 2015 at 7:45
  • That was ufw status at the time of the problem, and the status was identical once the problem was gone. I haven't been able to test reliably, but I was blocked on my hotel wifi, my mobile internet and google's page fetch feature. I didn't find a connection that let me through. Aug 11, 2015 at 9:41
  • Could it be invalid incoming packets (which by default seem to be blocked but reason for invalidity not logged). echo 255 >/proc/sys/net/netfilter/nf_conntrack_log_invalid should I think enable additional logging including diagnosis of faulty packet - see kernel.org/doc/Documentation/networking/nf_conntrack-sysctl.txt for more details. Aug 11, 2015 at 15:00

0

You must log in to answer this question.

Browse other questions tagged .