Unable to open port 8883 for MyQ garage opener

[johnpoz]

@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..

[cheapie408]

@johnpoz

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

[johnpoz]

@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..

[rcoleman-netgate]

@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.

[cheapie408]

@rcoleman-netgate

I'll let it run like this for half a day or so to see if there are any hickup on the app then I'll start removing all the rules to see what's the affect.

I followed some guide online for the DMZ setup

[rcoleman-netgate]

@cheapie408 Having your devices open from the public internet is not a good idea in any situation.

And, again, TCP 53 does nothing for DNS. DNS is a UDP service.

[johnpoz]

@rcoleman-netgate said in Unable to open port 8883 for MyQ garage opener:

Not to mention DNS is 53UDP, not 53TCP.

Yeah - its nonsense rule I agree.. There is no way no hell that device would ever need 53 inbound, and sure and not tcp 53..

Lets just state this yet again, like we did way back when when this thread started. That my chamberlin hub requires ZERO inbound ports to open..

I am sorry that their support is crappy ;) And sorry there is junk info on the internet.. Users trying to help users.. But I have a chamberlin hub, and can say for FACT there is ZERO inbound traffic needed to work. I get notified any time it opens or closes, and I can open it from my phone anywhere..Just from being signed into the MyQ app..

[cheapie408]

So MyQ has been working for the past 24 hours on the 2nd vlan the only thing I have enabled on it is the rules below

I disabled all the unnecessary rules on the LAN and moved the MyQ to it and it almost immediately reported to be offline. I have no clue what can be causing this.


[Derelict]

@cheapie408 MyQ doesn't require anything special. At least not the MyQ devices I have. They connect outbound to the MyQ infrastructure and so does the phone app.

This is my half-hearted attempt to isolate the IOT VLAN here. I have a few MyQ devices there, the generac, a rachio irrigation controller, a thermostat, etc.

Nothing is required inbound.

[Derelict]

And always pass both TCP and UDP for DNS (like that ) or you can get spurious, almost-impossible-to-diagnose failures when DNS switches to TCP to avoid fragmenting long responses, zone transfers, etc. Look at your unbound. It's listening on tcp/*.53 for a reason.

This article looks like it covers the basics pretty well.

ETA: This also illustrates why you should Reject instead of Block rules for connections from inside hosts. If you did limit outbound DNS connections to UDP-only and a client tried to make a TCP connection to a blocked server you would want it to receive an immediate RST (Connection refused) instead of sitting there waiting to time out again and again and again.