Unable to open port 8883 for MyQ garage opener
-
I think they are being typical support monkeys.
I remember it took a while to get them on the wifi but since I got that worked out they've been working fine. Opened the garage for my daughter while I was on the beach a couple states away. :)
-
These are the states:
IOT tcp 172.29.98.227:51798 -> 20.62.215.172:8883 ESTABLISHED:ESTABLISHED 4.391 K / 4.387 K 191 KiB / 178 KiB IOT tcp 172.29.98.228:61648 -> 40.83.217.203:8883 ESTABLISHED:ESTABLISHED 1.067 K / 1.064 K 47 KiB / 43 KiB IOT tcp 172.29.98.229:54858 -> 13.88.21.103:8883 ESTABLISHED:ESTABLISHED 240 / 237 12 KiB / 10 KiB
All outbound connections....
-
it's showing connected on my Wifi I can ping it and all. In fact it sits 3 ft from one of my AP. It's been showing online for awhile but the app says that it's offline.
It's annoying is that it would drop in and out. I'd send a command and it would not do anything and then in the middle of no where it would open or close the garage
-
btw I did a test port and received this. 171 is the address of the myq device
-
8883 is the port the cloud servers listen on, not the door openers. They connect to My-Q on TCP/8883 not the other way around. You might want to talk to the people who installed the opener to see if they understand how it all works.
-
@cheapie408 said in Unable to open port 8883 for MyQ garage opener:
Support said this needs to be open for it to work
As @Derelict stated this connection is outbound. I have a MyQ and I have NO Inbound ports to it at all. Works great..
What are you outbound rules?
-
@johnpoz The wisdom of doing this at all can be questioned lol. I can only hope that they are using something like a private key from the secure enclave to sign requests to open the doors and that they did it all right.
-
@derelict said in Unable to open port 8883 for MyQ garage opener:
that they did it all right.
I found this - does seem like there are some local stuff you can do via rf, etc.
IoT stuff is always a question.. But overall from this finishing comment, it seems to be one of the better implementations.
We would like to finish by commenting that the likelihood of a real-world attack on this target is low, based on the complexity of the attack and installation footprint. We have discussed this with Chamberlain, who has validated the findings and agrees with this assessment. Chamberlain has made clear efforts to build a secure product and appears to have eliminated much of the low-hanging fruit common to IoT devices
-
@johnpoz Good article. Thanks.
-
@derelict I'll have to dig into this. I already have an existing remote garage opener tied to HomeSeer this MyQ was an impulse buy more or less a backup so not critical. Maybe I'll hack it up and see if I can make it local.
-
@cheapie408 said in Unable to open port 8883 for MyQ garage opener:
Maybe I'll hack it up and see if I can make it local.
I don't know what that means but good luck.
-
Since I last posted this, I gave up and turned off my PFSense and moved to use the Xfinity Xfi router as my last resort. After several months, it was unbearable to deal with the Xfi router so I moved my network back to the PFSense.
While I was using the Xfi router and even an old Asus router the garage opener worked flawlessly. As soon as I moved it to the PFsense it acted up again.
Still looking for a solution to this. :(
-
@cheapie408
So when you check the states in pfSense, did you see your device connected to anything on destination port 8883?Is the device on a segmented network?
Are there other devices in its subnet, which can successfully connect to the internet?Possibly pfBlockerNG or something else is blocking the connection?
-
@cheapie408 Set up a VPN and stop opening ports for anything.
You'll be glad you did! -
@cheapie408 said in Unable to open port 8883 for MyQ garage opener:
Still looking for a solution to this. :(
Solution to what exactly.. There are no inbound traffic needed for this, there is no UPnP needed for this.. The chamberlin hub makes outbound connections on that port..
I just looked and here is mine
3.99 is my hub IP..
There is nothing in pfsense that would prevent this out of the box. Been working for years on pfsense for me - zero to do.. So unless you are blocking outbound traffic, there is nothing to do. Are you running IPS, or using block lists for ips in pfblocker?
-
I google this issue and there seems to be several other people with the exact issue.
For kicks, I added a DMZ VLAN on PFSense and Created a seperate network assigned to the DMZ VLan I only have the MyQ device on this and it has been working for the past hour.
-
@cheapie408 so your saying on the lan with any any rule it doesn't work, but on a new network say 192.168.2/24 instead of 192.168.1/24 and any any rules it works without any problems??
Think about that for like .2 seconds - does that even possible remotely sound like it could happen?
Are you routing traffic out a vpn? Have you messed with outbound nat other then automatic?
This works for years for me - even linked to article how this works. There is nothing special going on there - this is like your browser going to www.google.com - its just a different port.. Pfsense doesn't care what port your talking on outbound.. tcp is tcp is tcp, etc..
Maybe you had a duplicate IP setup for what IP your hub was? Without some actual specifics from you it is impossible what odd thing you had going on.. But there is nothing special you have to do in pfsense to allow that device to work.. That would work straight out of the box..
-
Here's what my rule looks like. I honestly don't know I've been doing so many different things and the only thing that works on setting up a DMZ VLAN
-
@cheapie408 those rules are pretty pointless.. You sure and the hell do not need anything on wan for it to work... Again there is NO INBOUND traffic needed for this tor work. And those rules on wan only come into play if you actually had a port forward setup..
Your lan rules are default out of the box any any rule..
Your bottom 3 rules on your dmz are pointless, since the rule above them is any any rule so they will never even be evaluated.
And the top rule is pretty pointless on dmz with tcp only, when your going to have a any any rule..
-
@johnpoz Not to mention DNS is 53UDP, not 53TCP.
@cheapie408 Removing all the WAN rules is a good start, and then verifying if you REALLY need those devices public to the internet without filtering... and then, from there, setting up a VPN to access them.
I used to open all the things I wanted out in the wild before I realized I was best suited making the VPN. Rarely do I need them on my phone and even more rarely do I find myself on a network that is blocking IPsec traffic.