# Ufw log fills up with \[BLOCK\] messages from node-red http gets
**URL:** https://discourse.nodered.org/t/ufw-log-fills-up-with-block-messages-from-node-red-http-gets/27500
**Category:** General
**Created:** [29 May 2020 16:12 UTC](https://discourse.nodered.org/t/ufw-log-fills-up-with-block-messages-from-node-red-http-gets/27500 "2020-05-29T16:12:42Z")
**Posts on this page:** 12
**Page:** 1
### Author:  [@brandock](https://discourse.nodered.org/u/brandock)
#### Post date: [29 May 2020 16:12 UTC](https://discourse.nodered.org/t/ufw-log-fills-up-with-block-messages-from-node-red-http-gets/27500/1 "2020-05-29T16:12:42Z")
I have node-red running on a Raspberry Pi, and on another Raspberry Pi I run emonCMS, ufw, and my apache2 reverse proxy server.
Some of my nod-red flows request the feed data from emonCMS. Like this one:
`[{"id":"a7ce24a2.0a2908","type":"http response","z":"287b3bb9.8d15b4","name":"","statusCode":"","headers":{},"x":810,"y":560,"wires":[]},{"id":"50fb6fe2.f9488","type":"http request","z":"287b3bb9.8d15b4","name":"Get Solar","method":"GET","ret":"obj","paytoqs":false,"url":"http://192.168.1.40/emoncms/feed/value.json?id=88085&apikey=xxxxxxxxxxxxxxx","tls":"","persist":false,"proxy":"","authType":"","x":320,"y":560,"wires":[["482a840e.3db4fc"]]},{"id":"f7063400.6f0358","type":"http in","z":"287b3bb9.8d15b4","name":"","url":"/solar","method":"get","upload":false,"swaggerDoc":"","x":140,"y":560,"wires":[["50fb6fe2.f9488"]]},{"id":"403ae3d0.4f9cec","type":"inject","z":"287b3bb9.8d15b4","name":"","topic":"","payload":"","payloadType":"date","repeat":"","crontab":"","once":false,"onceDelay":0.1,"x":140,"y":620,"wires":[["50fb6fe2.f9488"]]},{"id":"ed2af74.cd73b08","type":"debug","z":"287b3bb9.8d15b4","name":"","active":false,"tosidebar":true,"console":false,"tostatus":false,"complete":"false","x":750,"y":640,"wires":[]},{"id":"482a840e.3db4fc","type":"function","z":"287b3bb9.8d15b4","name":"","func":"value = Number(msg.payload);\nif (value < 30) value=0;\nvar solar = \n {\n \"title\": \"Solar\",\n \"value\":value,\n \"subtitle\":\"\"\n }\n\n\nmsg.payload = [solar]\nreturn msg;","outputs":1,"noerr":0,"x":530,"y":560,"wires":[["7ef8d070.82b7f"]]},{"id":"7ef8d070.82b7f","type":"json","z":"287b3bb9.8d15b4","name":"","property":"payload","action":"","pretty":false,"x":670,"y":560,"wires":[["ed2af74.cd73b08","a7ce24a2.0a2908"]]}]`
When these requests go over to the emonCMS server, the ufw.log fills up with [BLOCK] messages. Interestingly enough, the requests still go through, get responses, and the flow works. But emonCMS struggles with the log volume and /var/log quickly gets 100% full, which causes various other problems.
Here is what I've tried:
1. Edit `/etc/rsyslog.d/20-ufw.conf` and remove the comment character before the `&stop`
2. added a specific “allow” rule for traffic coming from 192.168.1.80, the IP of my node-red server
This hasn’t slowed down the logging a bit. I am suspicious that this is because the inbound hits from node-red all have different, seemingly random destination ports.
This is what I see in the log:
```auto
pi@emonpi:~$ tail -f /var/log/ufw.log
May 29 08:43:02 emonpi kernel: [39258.075608] [UFW BLOCK] IN=eth0 OUT= MAC=b8:27:eb:3d:21:50:b8:27:eb:e2:7d:67:08:00:45:00:00:28:00:00:40:00:40:06:b7:07 SRC=192.168.1.80 DST=192.168.1.40 LEN=40 TOS=0x00 PREC=0x00 TTL=64 ID=0 DF PROTO=TCP SPT=1880 DPT=54308 WINDOW=0 RES=0x00 RST URGP=0
May 29 08:43:32 emonpi kernel: [39288.157728] [UFW BLOCK] IN=eth0 OUT= MAC=b8:27:eb:3d:21:50:b8:27:eb:e2:7d:67:08:00:45:00:00:28:00:00:40:00:40:06:b7:07 SRC=192.168.1.80 DST=192.168.1.40 LEN=40 TOS=0x00 PREC=0x00 TTL=64 ID=0 DF PROTO=TCP SPT=1880 DPT=53602 WINDOW=0 RES=0x00 RST URGP=0
May 29 08:43:41 emonpi kernel: [39297.116653] [UFW BLOCK] IN=eth0 OUT= MAC=b8:27:eb:3d:21:50:b8:27:eb:e2:7d:67:08:00:45:00:00:28:00:00:40:00:40:06:b7:07 SRC=192.168.1.80 DST=192.168.1.40 LEN=40 TOS=0x00 PREC=0x00 TTL=64 ID=0 DF PROTO=TCP SPT=1880 DPT=54502 WINDOW=0 RES=0x00 RST URGP=0
May 29 08:44:02 emonpi kernel: [39318.237702] [UFW BLOCK] IN=eth0 OUT= MAC=b8:27:eb:3d:21:50:b8:27:eb:e2:7d:67:08:00:45:00:00:28:00:00:40:00:40:06:b7:07 SRC=192.168.1.80 DST=192.168.1.40 LEN=40 TOS=0x00 PREC=0x00 TTL=64 ID=0 DF PROTO=TCP SPT=1880 DPT=54502 WINDOW=0 RES=0x00 RST URGP=0
May 29 08:44:31 emonpi kernel: [39347.034810] [UFW BLOCK] IN=eth0 OUT= MAC=b8:27:eb:3d:21:50:b8:27:eb:e2:7d:67:08:00:45:00:00:28:00:00:40:00:40:06:b7:07 SRC=192.168.1.80 DST=192.168.1.40 LEN=40 TOS=0x00 PREC=0x00 TTL=64 ID=0 DF PROTO=TCP SPT=1880 DPT=53426 WINDOW=0 RES=0x00 RST URGP=0
May 29 08:45:05 emonpi kernel: [39380.492002] [UFW BLOCK] IN=eth0 OUT= MAC=b8:27:eb:3d:21:50:b8:27:eb:e2:7d:67:08:00:45:00:00:28:00:00:40:00:40:06:b7:07 SRC=192.168.1.80 DST=192.168.1.40 LEN=40 TOS=0x00 PREC=0x00 TTL=64 ID=0 DF PROTO=TCP SPT=1880 DPT=54112 WINDOW=0 RES=0x00 RST URGP=0
May 29 08:45:05 emonpi kernel: [39380.702926] [UFW BLOCK] IN=eth0 OUT= MAC=b8:27:eb:3d:21:50:b8:27:eb:e2:7d:67:08:00:45:00:00:28:00:00:40:00:40:06:b7:07 SRC=192.168.1.80 DST=192.168.1.40 LEN=40 TOS=0x00 PREC=0x00 TTL=64 ID=0 DF PROTO=TCP SPT=1880 DPT=54112 WINDOW=0 RES=0x00 RST URGP=0
May 29 08:45:35 emonpi kernel: [39410.732790] [UFW BLOCK] IN=eth0 OUT= MAC=b8:27:eb:3d:21:50:b8:27:eb:e2:7d:67:08:00:45:00:00:28:00:00:40:00:40:06:b7:07 SRC=192.168.1.80 DST=192.168.1.40 LEN=40 TOS=0x00 PREC=0x00 TTL=64 ID=0 DF PROTO=TCP SPT=1880 DPT=55624 WINDOW=0 RES=0x00 RST URGP=0
May 29 08:45:42 emonpi kernel: [39417.677312] [UFW BLOCK] IN=eth0 OUT= MAC=b8:27:eb:3d:21:50:b8:27:eb:e2:7d:67:08:00:45:00:00:28:00:00:40:00:40:06:b7:07 SRC=192.168.1.80 DST=192.168.1.40 LEN=40 TOS=0x00 PREC=0x00 TTL=64 ID=0 DF PROTO=TCP SPT=1880 DPT=55624 WINDOW=0 RES=0x00 RST URGP=0
May 29 08:46:03 emonpi kernel: [39438.562653] [UFW BLOCK] IN=eth0 OUT= MAC=b8:27:eb:3d:21:50:b8:27:eb:e2:7d:67:08:00:45:00:00:28:00:00:40:00:40:06:b7:07 SRC=192.168.1.80 DST=192.168.1.40 LEN=40 TOS=0x00 PREC=0x00 TTL=64 ID=0 DF PROTO=TCP SPT=1880 DPT=55624 WINDOW=0 RES=0x00 RST URGP=0
May 29 08:46:33 emonpi kernel: [39468.636009] [UFW BLOCK] IN=eth0 OUT= MAC=b8:27:eb:3d:21:50:b8:27:eb:e2:7d:67:08:00:45:00:00:28:00:00:40:00:40:06:b7:07 SRC=192.168.1.80 DST=192.168.1.40 LEN=40 TOS=0x00 PREC=0x00 TTL=64 ID=0 DF PROTO=TCP SPT=1880 DPT=55822 WINDOW=0 RES=0x00 RST URGP=0
May 29 08:47:05 emonpi kernel: [39500.991027] [UFW BLOCK] IN=eth0 OUT= MAC=b8:27:eb:3d:21:50:b8:27:eb:e2:7d:67:08:00:45:00:00:28:00:00:40:00:40:06:b7:07 SRC=192.168.1.80 DST=192.168.1.40 LEN=40 TOS=0x00 PREC=0x00 TTL=64 ID=0 DF PROTO=TCP SPT=1880 DPT=55064 WINDOW=0 RES=0x00 RST URGP=0
May 29 08:47:05 emonpi kernel: [39501.202692] [UFW BLOCK] IN=eth0 OUT= MAC=b8:27:eb:3d:21:50:b8:27:eb:e2:7d:67:08:00:45:00:00:28:00:00:40:00:40:06:b7:07 SRC=192.168.1.80 DST=192.168.1.40 LEN=40 TOS=0x00 PREC=0x00 TTL=64 ID=0 DF PROTO=TCP SPT=1880 DPT=55064 WINDOW=0 RES=0x00 RST URGP=0
May 29 08:47:35 emonpi kernel: [39531.122554] [UFW BLOCK] IN=eth0 OUT= MAC=b8:27:eb:3d:21:50:b8:27:eb:e2:7d:67:08:00:45:00:00:28:00:00:40:00:40:06:b7:07 SRC=192.168.1.80 DST=192.168.1.40 LEN=40 TOS=0x00 PREC=0x00 TTL=64 ID=0 DF PROTO=TCP SPT=1880 DPT=51778 WINDOW=0 RES=0x00 RST URGP=0
May 29 08:47:42 emonpi kernel: [39538.078087] [UFW BLOCK] IN=eth0 OUT= MAC=b8:27:eb:3d:21:50:b8:27:eb:e2:7d:67:08:00:45:00:00:28:00:00:40:00:40:06:b7:07 SRC=192.168.1.80 DST=192.168.1.40 LEN=40 TOS=0x00 PREC=0x00 TTL=64 ID=0 DF PROTO=TCP SPT=1880 DPT=51778 WINDOW=0 RES=0x00 RST URGP=0
May 29 08:48:01 emonpi kernel: [39556.318311] [UFW BLOCK] IN=eth0 OUT= MAC=b8:27:eb:3d:21:50:b8:27:eb:e2:7d:67:08:00:45:00:00:28:00:00:40:00:40:06:b7:07 SRC=192.168.1.80 DST=192.168.1.40 LEN=40 TOS=0x00 PREC=0x00 TTL=64 ID=0 DF PROTO=TCP SPT=1880 DPT=55064 WINDOW=0 RES=0x00 RST URGP=0
May 29 08:48:20 emonpi kernel: [39576.159361] [UFW BLOCK] IN=eth0 OUT= MAC=b8:27:eb:3d:21:50:b8:27:eb:e2:7d:67:08:00:45:00:00:28:00:00:40:00:40:06:b7:07 SRC=192.168.1.80 DST=192.168.1.40 LEN=40 TOS=0x00 PREC=0x00 TTL=64 ID=0 DF PROTO=TCP SPT=1880 DPT=55404 WINDOW=0 RES=0x00 RST URGP=0
May 29 08:48:43 emonpi kernel: [39598.317332] [UFW BLOCK] IN=eth0 OUT= MAC=b8:27:eb:3d:21:50:b8:27:eb:e2:7d:67:08:00:45:00:00:28:00:00:40:00:40:06:b7:07 SRC=192.168.1.80 DST=192.168.1.40 LEN=40 TOS=0x00 PREC=0x00 TTL=64 ID=0 DF PROTO=TCP SPT=1880 DPT=54862 WINDOW=0 RES=0x00 RST URGP=0
May 29 08:49:03 emonpi kernel: [39619.200628] [UFW BLOCK] IN=eth0 OUT= MAC=b8:27:eb:3d:21:50:b8:27:eb:e2:7d:67:08:00:45:00:00:28:00:00:40:00:40:06:b7:07 SRC=192.168.1.80 DST=192.168.1.40 LEN=40 TOS=0x00 PREC=0x00 TTL=64 ID=0 DF PROTO=TCP SPT=1880 DPT=56130 WINDOW=0 RES=0x00 RST URGP=0
May 29 08:49:31 emonpi kernel: [39647.197381] [UFW BLOCK] IN=eth0 OUT= MAC=b8:27:eb:3d:21:50:b8:27:eb:e2:7d:67:08:00:45:00:00:28:00:00:40:00:40:06:b7:07 SRC=192.168.1.80 DST=192.168.1.40 LEN=40 TOS=0x00 PREC=0x00 TTL=64 ID=0 DF PROTO=TCP SPT=1880 DPT=54862 WINDOW=0 RES=0x00 RST URGP=0
```
---
### Author:  [@TotallyInformation](https://discourse.nodered.org/u/TotallyInformation)
#### Post date: [29 May 2020 16:29 UTC](https://discourse.nodered.org/t/ufw-log-fills-up-with-block-messages-from-node-red-http-gets/27500/2 "2020-05-29T16:29:18Z")
I assume that you have done `sudo ufw allow 1880`?
Unless you want to allow access from the Internet, you should really of course use
```auto
sudo ufw allow from 192.168.1.0/24 to any port 1880
```
---
### Author:  [@brandock](https://discourse.nodered.org/u/brandock)
#### Post date: [29 May 2020 16:47 UTC](https://discourse.nodered.org/t/ufw-log-fills-up-with-block-messages-from-node-red-http-gets/27500/3 "2020-05-29T16:47:30Z")
> [@TotallyInformation](#):
>
> `sudo ufw allow from 192.168.1.0/24 to any port 1880`
This might be my lack of understanding of ufw, but wouldn't "udo ufw allow from 192.168.1.0/24 to any port 1880" open port 1880 as a destination port for inbound traffic? If you look at the [BLOCK] messages I'm getting, 1880 is the source port. The ports I would need to have open in ufw appear to be a myriad of somewhat random-looking ports like 55064, 56130, etc.
So what I've tried is "sudo ufw allow from 192.168.1.80" in the hope that this would ignore the port and just allow the traffic from this trusted server on my network. But it didn't work that way.
The source port of 1880 makes sense to me, because node-red is sending the http requests, but the destination ports I don't understand, and that is what brought me here.
---
### Author:  [@TotallyInformation](https://discourse.nodered.org/u/TotallyInformation)
#### Post date: [29 May 2020 17:04 UTC](https://discourse.nodered.org/t/ufw-log-fills-up-with-block-messages-from-node-red-http-gets/27500/4 "2020-05-29T17:04:06Z")
I'm a little rusty on UFW myself.
> [@brandock](#):
>
> open port 1880 as a destination port for inbound traffic
I thought that is what you were trying to do? If not, my bad.
Normally, the default would be block everything in, let everything out. So you build out from there, allowing access inbound to specific services from as specific a location as possible.
Lets take a step back. Which IP address is which and in what direction are you actually trying to make a request?
.40 is emonpi (so running emon) and .80 is running Node-RED? And UFW is running on which device - .40?
If so, the request should be coming from the .80 and .40 should simply be responding which, unless you've made other changes to UFW, it would be able to do anyway.
The output shows that the request is coming from .80 and arriving at .40 on eth0 as expected.
I got the ports wrong though because, as you say, the request comes _from_ port 1880 but arrives at a dynamic set of ports. So you are correct that you should open port range 50000-60000 or just allow any request from .80
By the looks of it, UFW is blocking repeated requests on different ports until it finds one that it likes - that's why you do get the data, but it is taking longer than expected (though probably still too fast to notice) because it is having to try multiple ports.
Is there a way to fix the port on emon?
---
### Author:  [@brandock](https://discourse.nodered.org/u/brandock)
#### Post date: [29 May 2020 18:06 UTC](https://discourse.nodered.org/t/ufw-log-fills-up-with-block-messages-from-node-red-http-gets/27500/5 "2020-05-29T18:06:03Z")
> [@TotallyInformation](#):
>
> .40 is emonpi (so running emon) and .80 is running Node-RED? And UFW is running on which device - .40?
Correct. .40 is emonpi running emonCMS, .80 is Node-RED. And yes, UFW is on .40.
> [@TotallyInformation](#):
>
> Is there a way to fix the port on emon?
I have full control of the ports on the emonPi, in the sense that it is my personal Raspberry Pi, but maybe I just haven't made the right changes. Here is the current state of ufw, with all the various things I've been trying. Any suggestions?
```auto
To Action From
-- ------ ----
80/tcp ALLOW IN Anywhere
443/tcp ALLOW IN Anywhere
22/tcp ALLOW IN Anywhere
1883/tcp ALLOW IN Anywhere
1880/tcp ALLOW IN Anywhere
Anywhere ALLOW IN 192.168.1.80
1880 ALLOW IN 192.168.1.0/24
80/tcp (v6) ALLOW IN Anywhere (v6)
443/tcp (v6) ALLOW IN Anywhere (v6)
22/tcp (v6) ALLOW IN Anywhere (v6)
1883/tcp (v6) ALLOW IN Anywhere (v6)
1880/tcp (v6) ALLOW IN Anywhere (v6)
```
---
### Author:  [@TotallyInformation](https://discourse.nodered.org/u/TotallyInformation)
#### Post date: [29 May 2020 19:51 UTC](https://discourse.nodered.org/t/ufw-log-fills-up-with-block-messages-from-node-red-http-gets/27500/6 "2020-05-29T19:51:01Z")
Are there any blocks at all?
Somewhat as an aside, personally I would restrict IPv6 alltogether unless you really need it. I would also remove the 1880, 1883 (MQTT) and 22 (SSH) entries. If you really want to allow remote SSH from the Internet, you should move it to a different port \>1024, that stops lots of automated attacks.
---
### Author:  [@brandock](https://discourse.nodered.org/u/brandock)
#### Post date: [30 May 2020 16:10 UTC](https://discourse.nodered.org/t/ufw-log-fills-up-with-block-messages-from-node-red-http-gets/27500/7 "2020-05-30T16:10:14Z")
> [@TotallyInformation](#):
>
> Are there any blocks at all?
It is pretty wide open right now, as I try to get the logging to be less verbose and figure out why the [BLOCK] is happening. In reality, my .40 machine sits behind my router, which only forwards ports 80 and 443, and sometimes I open a different port \> 1024 to forward to 22 if I need it. I am not an expert, but it makes me wonder if ufw is really needed on .40 because of this. Thoughts on that?
---
### Author:  [@TotallyInformation](https://discourse.nodered.org/u/TotallyInformation)
#### Post date: [30 May 2020 16:42 UTC](https://discourse.nodered.org/t/ufw-log-fills-up-with-block-messages-from-node-red-http-gets/27500/8 "2020-05-30T16:42:02Z")
> [@brandock](#):
>
> but it makes me wonder if ufw is really needed on .40 because of this. Thoughts on that?
Well, it does give an extra layer of security but as long as you trust your router's configuration and firewall and you are only exposing 443 and a non-standard port for SSH there is probably little risk. I would turn off port 80 though if you can.
As you may have seen me say elsewhere, you can further strengthen your on-site security by only allowing incoming TLS secured connections from Cloudflare, using Cloudflare as an external proxy. This is much stronger because anyone (more likely anything) probing your router external IP address will get nothing back even on your open port.
What version of Rasbian are you using by the way? I think that Buster has replaced IPTABLES with something else hasn't it? Certainly Debian Buster has replaced IPTABLES with nftables. NFTABLES is supposed to be a lot easier to work with and you probably don't really need UFW to help.
[https://wiki.debian.org/nftables](https://wiki.debian.org/nftables)
[https://wiki.nftables.org/wiki-nftables/index.php/Moving\_from\_iptables\_to\_nftables](https://wiki.nftables.org/wiki-nftables/index.php/Moving_from_iptables_to_nftables)
---
### Author:  [@Paul-Reed](https://discourse.nodered.org/u/Paul-Reed)
#### Post date: [30 May 2020 18:10 UTC](https://discourse.nodered.org/t/ufw-log-fills-up-with-block-messages-from-node-red-http-gets/27500/9 "2020-05-30T18:10:47Z")
> [@TotallyInformation](#):
>
> you can further strengthen your on-site security by only allowing incoming TLS secured connections from Cloudflare, using Cloudflare as an external proxy
That's how my system is configured. I have a script which auto updates UFW with the IP addresses used by Cloudflare, if OP is interested - [GitHub - Paul-Reed/cloudflare-ufw: Script to update UFW with Cloudflare IPs](https://github.com/Paul-Reed/cloudflare-ufw)
---
### Author:  [@brandock](https://discourse.nodered.org/u/brandock)
#### Post date: [31 May 2020 13:58 UTC](https://discourse.nodered.org/t/ufw-log-fills-up-with-block-messages-from-node-red-http-gets/27500/10 "2020-05-31T13:58:36Z")
Thanks, Paul and TotallyInormation! I'm interested in going the Cloudflare route. I have some questions about what this would look like:
Where would my fleet of Raspberry Pis site in my home network if I were to use Cloudflare as my reverse proxy? Right now they are all behind my Apple router's firewall, with ports 443 and (for now at least) 80 forwarding to .40, which is my reverse proxy, as described above. Would I now put them all _outside_ my router's firewall, and use ufw to block all traffic not inbound from the Cloudflare reverse proxy? It seems like if I added Cloudflare to my current configuration my traffic would be going through two reverse proxies, mine and Cloudflare's.
---
### Author:  [@TotallyInformation](https://discourse.nodered.org/u/TotallyInformation)
#### Post date: [1 June 2020 22:41 UTC](https://discourse.nodered.org/t/ufw-log-fills-up-with-block-messages-from-node-red-http-gets/27500/11 "2020-06-01T22:41:44Z")
You can keep everything pretty much the same. The first step is to ensure that you have a public domain name that you can use at least part of and to reassign the DNS servers to Cloudflare.
Then you create a sub-domain (which could be www. if you want) and make the IP address point to the IP address for your home WAN, the one assigned by the ISP. Then configure whatever security you want in Cloudflare including using their own generic cert instead of your own.
Once you've made sure that works, then you can change your home router to ban access to ports 80/443 _except_ from the Cloudflare servers.
Now everyone has to come in via the Cloudflare proxy and cannot come direct to your home IP address.
Once you are sure everything is working, you can choose whether you also keep your local reverse proxy depending on what you are doing. You probably won't need it though.
> [@brandock](#):
>
> ufw to block all traffic not inbound from the Cloudflare reverse proxy
Better to control that at the edge firewall, that way you know for sure that nothing can get into your network.
> [@brandock](#):
>
> It seems like if I added Cloudflare to my current configuration my traffic would be going through two reverse proxies, mine and Cloudflare's.
That is correct while that adds some overhead, it lets you use your local proxy to terminate the TLS between Cloudflare and your network, something that you really want. In addition, you can choose whether you want to use Cloudflare or your local proxy to provide any logins. The free Cloudflare logins are limited to, I think, 5 user id's.
```auto
[Internet cloud] -> Cloudflare Proxy (+ DNS, Cert) -> Home Router/Firewall -> *Pi's
```
Here is some of the stuff that you get from Cloudflare for free - this mainly from my blog:
---
### Author:  [@system](https://discourse.nodered.org/u/system)
#### Post date: [31 July 2020 22:41 UTC](https://discourse.nodered.org/t/ufw-log-fills-up-with-block-messages-from-node-red-http-gets/27500/12 "2020-07-31T22:41:46Z")
This topic was automatically closed 60 days after the last reply. New replies are no longer allowed.