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 52813 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.
Parents
  • 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

Reply
  • 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

Children
No Data
Unfiltered HTML