Firewall Blocking Ropieee Communication to Internet

CRo · May 1, 2021, 8:52pm

Hi Harry,

my firewall has been reporting thousands (essentially non-stop, every few seconds) of connection attempts originating from from my Ropieee to destination 34.75.196.16 port 9200. The reason for dropping the connection attempts is because of the intrusion prevention rule “SURICATA STREAM FIN recv but no session”.

Ropieee works fine. I guess if you say “that’s normal” then it’s no skin off my back, doesn’t cost me anything to have the firewall block the connections. However, it does create thousands of log entries.

If you think this is NOT OK, then I sure do want to know about it.

Thnx.

spockfish · May 2, 2021, 8:24am

Hi Chris,

Is this an XL or regular unit?

Thanks

CRo · May 2, 2021, 9:41am

Hi Harry,

it’s a normal non-XL Ropieee on a Pi 3B connected via ethernet. I don’t have any extra stuff installed on it, well that I know of. It is a pretty old installation… been upgraded many many times now.

The firewall log entries look like this:

I don’t think this behaviour is new, I think that I just noticed it because I started to generate reports. =)

I could grab a new Ropieee und install again. In fact… I think I need to do that no matter what, because either it stops the log entries or it doesn’t.

A seperate question is: OK, so, why does the firewall think it wants to block these connection attempts? I can contact the vendor (Untangle) and ask them for their opinion.

So… an interesting situation.

Sincerely

Chris

CRo · May 2, 2021, 9:46am

Oh cool… and I see in my screen shot that the destination has changed, but it’s still the same network provider (34.75.). And the same port…

So, 192.168.0.211 is the Ropieee.

CRo · May 3, 2021, 10:20am

Port 9200 is used by wap-wsp.

Stopping the Ropieee stops the connection attempts (that much is consistent).

In total (of the 20000 log entries I’ve looked at), the Ropieee Pi has tried to make port 9200 connections to the following IPs:

35.237.106.222
35.227.6.128
34.75.196.16
104.196.205.85
35.243.240.56
35.196.73.153

Interestingly, port 9200 is open on the Roon Server itself:
# ss -tulpn | grep 9200
tcp LISTEN 0 10 0.0.0.0:9200 0.0.0.0:* users:((“RAATServer”,pid=2229224,fd=25))

This got me to look for port 9200 connections from any device on my LAN. And bingo: the Linux box running the Roon Server has also made port 9200 connections to some of the those same addresses. Of 20000 logged entries (just about all of which came from Ropieee) the only other device that made a port 9200 connection to the internet, 30 times in total, was the RoonServer system, and they were to the following IPs:

104.196.205.85
35.237.106.222
35.196.73.153

So, my guess is, if this is not from the code you wrote Harry, that it has to do with the Roon Bridge running on the Pi.

So, now I’ll have tcpdump running and I’ll have a look at what exactly Ropieee and the RoonServer are doing with port 9200 in that recurdding list of IPs.

Cheers

Chris

CRo · May 3, 2021, 12:25pm

Hi Harry,

the connections to port 9200 of unidentified servers on the net doesn’t seem to have anything to do with Ropieee in and of itself, other than ofcourse that Ropieee is a Roon Bridge. It seems to be the Roon software talking with an array of servers out there.

I come to that conclusion after I downloaded the latest Ropieee bin and rewrote the SD card of the Pi, re-configured Ropieee, watching the entire time with the packet tracer.

Here we see the RoonServer and Ropieee talking with whatever is out there at exactly the same time.

wap-wsp = port 9200
192.168.0.10 = RoonServer
192.168.0.211 = Ropieee

13:51:25.158741 IP 192.168.0.10.35676 > 34.73.66.119.wap-wsp: Flags [P.], seq 1013187616:1013187617, ack 979881604, win 229, options [nop,nop,TS val 1679650987 ecr 16
3530060], length 1                                                                                                                                                   
13:51:25.158746 IP 192.168.0.10.35676 > 34.73.66.119.wap-wsp: Flags [P.], seq 0:1, ack 1, win 229, options [nop,nop,TS val 1679650987 ecr 163530060], length 1       
13:51:25.240857 IP 192.168.0.211.57874 > 34.73.66.119.wap-wsp: Flags [P.], seq 2054820151:2054820152, ack 1876550703, win 256, length 1                              
13:51:25.240865 IP 192.168.0.211.57874 > 34.73.66.119.wap-wsp: Flags [P.], seq 0:1, ack 1, win 256, length 1

Here’s more detail of the connections comming from Ropieee:

14:01:25.241912 IP 192.168.0.211.57874 > 34.73.66.119.wap-wsp: Flags [P.], seq 2054820153:2054820154, ack 1876550703, win 256, length 1
14:01:25.241917 IP 192.168.0.211.57874 > 34.73.66.119.wap-wsp: Flags [P.], seq 0:1, ack 1, win 256, length 1
14:02:07.326762 IP 192.168.0.211.57888 > 34.73.66.119.wap-wsp: Flags [S], seq 3987561449, win 32767, options [mss 1460,nop,nop,sackOK,nop,wscale 7], length 0
14:02:07.326767 IP 192.168.0.211.57888 > 34.73.66.119.wap-wsp: Flags [S], seq 3987561449, win 32767, options [mss 1460,nop,nop,sackOK,nop,wscale 7], length 0
14:02:07.439046 IP 192.168.0.211.57888 > 34.73.66.119.wap-wsp: Flags [.], ack 2870230337, win 256, length 0
14:02:07.439051 IP 192.168.0.211.57888 > 34.73.66.119.wap-wsp: Flags [.], ack 1, win 256, length 0
14:02:07.439624 IP 192.168.0.211.57888 > 34.73.66.119.wap-wsp: Flags [P.], seq 0:10, ack 1, win 256, length 10
14:02:07.439628 IP 192.168.0.211.57888 > 34.73.66.119.wap-wsp: Flags [P.], seq 0:10, ack 1, win 256, length 10
14:02:07.440063 IP 192.168.0.211.57888 > 34.73.66.119.wap-wsp: Flags [P.], seq 10:57, ack 1, win 256, length 47
14:02:07.440066 IP 192.168.0.211.57888 > 34.73.66.119.wap-wsp: Flags [P.], seq 10:57, ack 1, win 256, length 47
14:02:50.794941 IP 192.168.0.211.57888 > 34.73.66.119.wap-wsp: Flags [F.], seq 57, ack 1, win 256, length 0
14:02:50.794950 IP 192.168.0.211.57888 > 34.73.66.119.wap-wsp: Flags [F.], seq 57, ack 1, win 256, length 0
14:02:50.795188 IP 192.168.0.211.57874 > 34.73.66.119.wap-wsp: Flags [F.], seq 1, ack 1, win 256, length 0
14:02:50.795202 IP 192.168.0.211.57874 > 34.73.66.119.wap-wsp: Flags [F.], seq 1, ack 1, win 256, length 0
14:02:50.906220 IP 192.168.0.211.57888 > 34.73.66.119.wap-wsp: Flags [.], ack 2, win 256, length 0
14:02:50.906226 IP 192.168.0.211.57888 > 34.73.66.119.wap-wsp: Flags [.], ack 2, win 256, length 0
14:03:44.694558 IP 192.168.0.211.33706 > 34.73.66.119.wap-wsp: Flags [S], seq 2325666816, win 32767, options [mss 1460,nop,nop,sackOK,nop,wscale 7], length 0
14:03:44.694565 IP 192.168.0.211.33706 > 34.73.66.119.wap-wsp: Flags [S], seq 2325666816, win 32767, options [mss 1460,nop,nop,sackOK,nop,wscale 7], length 0
14:03:44.805816 IP 192.168.0.211.33706 > 34.73.66.119.wap-wsp: Flags [.], ack 753614251, win 256, length 0
14:03:44.805820 IP 192.168.0.211.33706 > 34.73.66.119.wap-wsp: Flags [.], ack 1, win 256, length 0
14:03:44.807938 IP 192.168.0.211.33706 > 34.73.66.119.wap-wsp: Flags [P.], seq 0:10, ack 1, win 256, length 10
14:03:44.807941 IP 192.168.0.211.33706 > 34.73.66.119.wap-wsp: Flags [P.], seq 0:10, ack 1, win 256, length 10
14:03:44.808551 IP 192.168.0.211.33706 > 34.73.66.119.wap-wsp: Flags [P.], seq 10:57, ack 1, win 256, length 47
14:03:44.808555 IP 192.168.0.211.33706 > 34.73.66.119.wap-wsp: Flags [P.], seq 10:57, ack 1, win 256, length 47
14:08:44.811010 IP 192.168.0.211.33706 > 34.73.66.119.wap-wsp: Flags [P.], seq 57:58, ack 1, win 256, length 1
14:08:44.811017 IP 192.168.0.211.33706 > 34.73.66.119.wap-wsp: Flags [P.], seq 57:58, ack 1, win 256, length 1

Dear @support what does RoonServer and RoonBridge do talking to port 9200 of various IPs on the internet, such as

35.237.106.222
35.227.6.128
34.75.196.16
104.196.205.85
35.243.240.56
35.196.73.153
34.73.66.119

?

And… is it important? I assume it’s fine that my firewall thinks this an intrusion attempt and (atleast partially) blocks the sessions.

Sincerely

Chris

Nepherte · May 3, 2021, 12:37pm

Those ip addresses seem to be associated with google’s cloud infrastructure, on which Roonlabs hosts their backend.

CRo · May 4, 2021, 7:39am

Hi Bart,

yes, that seems quite plausible.

If that is the case, we’ve identified the cause of the connections.

What remains is to decide what to do about the firewall blocking them. Now that I know what is going on (it’d be nice if @support could confirm that what we infer is correct) I’m also fine with either ignoring the log entries or making a rule that explicitly allows the connections (but to do that I’d need a list of the target servers.)

beka · May 4, 2021, 5:51pm

Hey @CRo,

Thanks for the very detailed account of what you’re experiencing. The best way we can help is by taking this to our technical team.

I’ve moved your post to the #support category, so they can share any insights they have.

Thanks in advance for your patience while they get a chance to reply

CRo · May 4, 2021, 6:13pm

Excellent, thanks!

CRo · May 7, 2021, 7:16am

Right, so to summarize, these IPs are all part of bc.googleusercontent.com, ASN 15169 - GOOGLE, and from the protocol we could infer to be for Roon’s elastic search (“an open-source, RESTful, distributed search and analytics engine built on Apache Lucene” for those who aren’t familiar with it) backend.

Since Roon seems to work. I guess it’s not critical that the firewall is unhappy with these connection attempts. Maybe some other customers are also unknowingly blocking these, but probably only those (perhaps mostly SMBs or IT pros from home) using equipment that does intrusion prevention would notice any of it.

However, blocking legitimate traffic is not a good idea and just fills the logs up and possibly reduces the performance of the application (Roon). So, I’d still be happy to hear something from the Roon developers to that effect.