Thread Info
  • State Suggested Answer
  • +2 person also asked this people also asked this
  • Locked Locked
  • Replies 21 replies
  • Answers 1 answer
  • Subscribers 13 subscribers
  • Views 52783 views
  • Users 0 members are here
Options
Suggested
This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

Sophos UTM 9 and iRobot Roomba 980 Port 8883

Joshua Van Buskirk

Want to take a quick moment to say hello before asking my question.  I've been a long time lurker on these forums, and this seems to be a great community.  I'm a corporate Sophos end user as we employ UTM on Sophos hardware in our IT environment.  However, I'm also now using UTM home edition at home so I can better learn how to take advantage of the hardware we use in our corporate environment.

So onto the question with a bit of background first.  Several weeks ago I purchase an iRobot Roomba 980 vacuum cleaner.  This model has the ability to connect to the Internet for the purpose of downloading firmware updates, and for remote control and scheduling.  The initial firmware that the robot came with communicated with the iRobot cloud via HTTP and HTTPS.  This posed no issue with my home UTM and I was able to access and control the robot remotely from outside of my home network.  However, after the first night the robot received an update.  The robot now communicates via HTTP, HTTPS, and MQTT (TCP Port 8883).  The problem is, after the firmware update to the robot I can no longer access the robot from outside of my home network.  iRobot also isn't receiving communications from the robot regarding its status.

My home UTM is running 9.413-4 and I have created several rules to allow the 8883 traffic (which I believe is the issue) but the remote access is still not working. I pulled a packet capture off the UTM for traffic going to the robot or from the robot.  I provided that capture to the iRobot Corporation and they said that it appears as though the robot is having trouble communicating via 8883.

Here's what I've done so far to fix:

  1. Created a DNAT rule to allow Any traffic via TCP 8883 to the external WAN address, change destination to robot, service to field was left blank - set automatic firewall rule
  2. Created a DNAT rule to allow Any traffic via TCP 1883 to the external WAN address, change destination to robot, service to field was left blank - set automatic firewall rule
  3. Created a firewall rule to allow Any traffic from the robot to Any and the Internal address
  4. Added robot to Transparent Mode Skiplist for both source and destination under the Misc tab of Web Protection Filtering Options
  5. Created an Exception in Intrusion Prevention skipping Intrusion, Portscan, TCP SYN Flood, UDP Flood, and ICMP Flood Protection for all requests from the robot OR going to the robot

If anyone can help me with my struggle to get this robot working properly online it would be greatly appreciated.  The robot has even been replaced once as iRobot wasn't sure it wasn't the robot when I told them I had forwarding rules in place for port 8883.

Any assistance would be greatly appreciated!

Kindest regards,

Josh



This thread was automatically locked due to age.
  • 0

    Hi, Josh, and welcome to the UTM Community!

    Start by doing #1 in Rulz.  If that doesn't give you any hints, follow through with it's suggestion to consider #3 through #5.

    Cheers - Bob

     
    Sophos UTM Community Moderator
    Sophos Certified Architect - UTM
    Sophos Certified Engineer - XG
    Gold Solution Partner since 2005
    MediaSoft, Inc. USA
  • 0

    Any progress on this matter? My irobot roomba have the same issue and I really need a solution

  • 0 in reply to Wayne Sweeney

    Chào anh, and welcome to the UTM Community!

    What result did you get when you tried my suggestion above?

    Cheers - Bob

     
    Sophos UTM Community Moderator
    Sophos Certified Architect - UTM
    Sophos Certified Engineer - XG
    Gold Solution Partner since 2005
    MediaSoft, Inc. USA
  • 0 in reply to BAlfson

    As the initial topic poster I wanted to thank you for your reply Bob.  Unfortunately I got busy and failed to post back regarding this issue.  I had already gone over the rulz and they provided me with no solution.  I ended up removing the UTM from my home network for the time being as I was unable to find a solution.

    Regards,

     

    Josh

  • 0

    I'm having problems with my iRobot Roomba 880 and 980. I'd really appreciate some help!

  • 0 in reply to george balanchine

    Hi, and welcome to the UTM Community!

    What result did you get when you tried my suggestion above?

    Cheers - Bob

     
    Sophos UTM Community Moderator
    Sophos Certified Architect - UTM
    Sophos Certified Engineer - XG
    Gold Solution Partner since 2005
    MediaSoft, Inc. USA
  • 0 in reply to BAlfson

    I have been researching this issue in depth this week, as I have the same problem.  My Roomba is sending requests to the cloud, but the return traffic is getting dropped for some reason.  Everything except basic firewall is disabled my UTM configuration.  I also pulled and correlated the DNS query.  Using a different access point did not solve the problem (I didn't expect it to - just know Roomba states certain APs are "incompatible".

    While it states "packet filter rule # 3" I do see that my rule for 192.168.5.105 on any port and destination (as a test - will lock down later) is actually numbered 4 in the list.  I have three other rules above it that are automatically created, but rule # 3 does not have anything to do with it, and is not logged.  So I think it is a flaw in the numbering in Sophos logging or the UI because the rule it is hitting is triggered to log.  Regardless, the response is dropping.

    2017-10-12 23:16:56.209976 IP 192.168.5.105.49153 > 8.8.8.8.53: 1+ A? disc-prod.iot.irobotapi.com. (45)
    2017-10-12 23:16:56.265005 IP 8.8.8.8.53 > 192.168.5.105.49153: 1 8/0/0 A 54.192.6.60, A 54.192.6.27, A 54.192.6.81, A 54.192.6.232, A 54.192.6.48, A 54.192.6.40, A 54.192.6.181, A 54.192.6.215 (173)

    23:16:56 Packet filter rule #3 TCP  
    192.168.5.105 : 49153
    		→
    54.192.6.60 : 443
    		 
    [SYN] len=44 ttl=254 tos=0x00 srcmac=80:a5:89:71:66:54 dstmac=xx
    23:16:57   TCP  
    54.192.6.60 : 443
    		→
    ISP IP : 49153
    		 
    [RST] len=40 ttl=246 tos=0x00
    23:16:57 Default DROP TCP  
    54.192.6.60 : 443
    		→
    ISP IP : 49153
    		 
    [RST] len=40 ttl=246 tos=0x00 srcmac=00:01:5c:65:88:46 dstmac=xxx
    23:16:57   TCP  
    54.192.6.60 : 443
    		→
    ISP IP : 49153
    		 
    [RST] len=40 ttl=246 tos=0x00
    23:16:58 Default DROP TCP  
    54.192.6.60 : 443
    		→
    ISP IP : 49153
    		 
    [RST] len=40 ttl=246 tos=0x00 srcmac=00:01:5c:65:88:46 dstmac=xx
  • 0 in reply to Brandon E

    Additionally, conntrack -L a few minutes later.

     

    loginuser@fw:/usr/sbin > sudo ./conntrack -L | grep 192.168.5.105
    udp 17 138 src=192.168.5.105 dst=8.8.8.8 sport=49153 dport=53 packets=2 bytes=150 src=8.8.8.8 dst=ISP IP sport=53 dport=49153 packets=2 bytes=406 [ASSURED] mark=1048576 delta-time=43 helper=dns use=1
    tcp 6 259 ESTABLISHED src=192.168.5.105 dst=13.32.241.84 sport=49162 dport=443 packets=1 bytes=1440 [UNREPLIED] src=13.32.241.84 dst=ISP IP sport=443 dport=49162 packets=0 bytes=0 mark=1048576 delta-time=41 use=1
    conntrack v1.4.2 (conntrack-tools): 38 flow entries have been shown.
    tcp 6 86359 ESTABLISHED src=192.168.5.105 dst=13.32.241.219 sport=49163 dport=443 packets=8 bytes=1017 src=13.32.241.219 dst=ISP IP sport=443 dport=49163 packets=9 bytes=3401 [ASSURED] mark=1048576 delta-time=41 use=1
    tcp 6 255 ESTABLISHED src=192.168.5.105 dst=54.230.7.152 sport=49157 dport=443 packets=1 bytes=1440 [UNREPLIED] src=54.230.7.152 dst=ISP IP sport=443 dport=49157 packets=0 bytes=0 mark=1048576 delta-time=46 use=1

  • 0 in reply to Brandon E

    Hi, Brandon, and welcome to the UTM Community!

    I've not seen incorrect numbering in the firewall log file, but I rarely use the Live Log.  Alone among the logs, the Firewall Live Log presents abbreviated information in a format easier to read quickly.  Usually, you can't troubleshoot without looking at the corresponding line from the full Firewall log file.  Please post the line corresponding to the one listed with "Packet filter rule #3" above.

    It's not unusual for there to be RST packets dropped, so those don't tell us much.  We'd need to look at tcpdump to prove it, but my guess is that the ACK from 54.192.6.60 was received and that conntrack thought the conversation was finished, resulting in dropped RST packets.

    What does IPS IP represent?

    Cheers - Bob

     
    Sophos UTM Community Moderator
    Sophos Certified Architect - UTM
    Sophos Certified Engineer - XG
    Gold Solution Partner since 2005
    MediaSoft, Inc. USA
  • 0 in reply to BAlfson

    Thanks Bob.  Over the last few weeks, iRobot replaced my unit with another 980 due to some problems it was having completing a job.  I received a model 989, and immediately noticed the firmware was around 1.6, and successfully connecting and working with the cloud.   HOWEVER, as soon as the unit auto upgraded that night, the connectivity problems reappeared.  I have tcpdump'd both of my interfaces and investigated via Wireshark, and I have been determined to fix this.  The TLS 1.2 session packets are not much help, and I was unsuccessful in my attempt to SSL intercept the traffic from the Roomba; most likely because the onboard software does not trust my self-signed root CA.  I returned my UTM configuration back to it's original state (no proxy, no IPS service etc; only firewall rules)

    I performed another tcpdump and I reset Roomba to force traffic.

    sudo ./tcpdump -s 65535 -i any -w /home/login/dumptesteth0and1

    In Wireshark, I looked for any evidence suggesting the need for uPNP (e.g. iRobot servers calling and initiating connections directly to my external IP,  uPNP requests, etc).  I found nothing.

    I did however, find that Roomba tcp traffic to d2btmaffbxophg.cloudfront.net on a few different IPs were flagged as black background with red lettering in Wireshark; evidence of outbound TCP re transmission attempts. 

    I am stumped.  From what I can tell, it seems as if the complete conversation with the cloud is not able to occur.  The lack of SSL visibility adds additional challenges.

    Any ideas?

Unfiltered HTML