Required Ports for Vera communications LAN & Internet?

I have searched everywhere not finding anything definitive.

MCV’s Wiki says communications all happen over port 80… this is 100% bull. If I block all but port 80 the Vera cannot communicate to the MCV servers, thus I cannot login from the Internet → Vera or from the Vera’s Apps page.

A few user posts say port 37 & 230 are needed… but these did not help.

It is a known problem the Vera causes Onkyo receivers to have network problems - the Vera responds to uPnP requests killing the Onkyo’s networking ability. There is no way to turn off the Vera’s uPnP so I need to block the ports. I’d like to block ALL unnecessary ports just to make things easier and avoid problem with other things in the future.

If you know what ports are required for the Vera please let me know. Thank you

Port 80 is for the local web access to Vera’s UI.
Port 49451 and 3480 are for the api/http commands
Port 22 is for ssh

These are ports that Vera listens to. The ports that Vera connects to for other services can very based on your setup and plugins etc.

  • Garrett

Log into the Vera over SSH and run netstat, and you will get a list of the ports that it is listening on.

Blocking UPnP is tricky, because it involves multicast UDP (to 239.255.255.250) and UDP control ports that vary (possibly 49152, not always). Subnetting normally doesn’t forward multicast, which is why doing so works to solve the Onkyo UPnP problem.

NTP, if you enable it, is over UDP port 123, incoming and outgoing. rdate might be that port 37 you mentioned. Better not block those or you prevent Vera from learning the time.

TCP port 80 is the only port that is forwarded outside of your LAN to the secure MiOS servers (over a secure SSH tunnel, port 232 rings a bell).

I have tried keeping open all the ports you guys mention (80,22,37,123,232,3480,49451) while blocking all others - Vera cannot communicate with the internet. I have input a static IP address, GW, etc into the Vera and gave it a DHCP reservation in my router (Tomato firmware).

I looked at Netstat and there are a ton of ports in use… no rhyme or reason I can see.

I’m going to open a ticket… MCV needs to publish exactly what ports they use and how.

Aaron, be sure you are not conflating outgoing ports with incoming ports. Port 232, for instance, is the destination port on the MiOS remote-access server. The source port of the outgoing connection from Vera will be something else, perhaps random. You may have inadvertently blocked it.

Perhaps you have not made this mistake, but it’s a common one, along with confusing TCP and UDP, which I’m also worried that you are doing.

Be careful to NOT block outgoing ports from Vera … You will break a lot of plugins.
Unless you consider the plugins a virus :slight_smile:

I’m with you… I’m worried about blocking ports that are causing the problem with the Onkyo… but After more investigation, I think it may not be an issue with uPnP as others have previously stated. When the Vera is on, the Onkyo attempts to get an IP Address using DHCP, but it fails.

Vera is on…

Jan 5 16:30:44 unknown daemon.info dnsmasq-dhcp[12794]: DHCPDISCOVER(br0) 00:09:b0:46:aa:aa Jan 5 16:30:44 unknown daemon.info dnsmasq-dhcp[12794]: DHCPOFFER(br0) 192.168.2.12 00:09:b0:46:aa:aa Jan 5 16:30:47 unknown daemon.info dnsmasq-dhcp[12794]: DHCPDISCOVER(br0) 00:09:b0:46:aa:aa Jan 5 16:30:47 unknown daemon.info dnsmasq-dhcp[12794]: DHCPOFFER(br0) 192.168.2.12 00:09:b0:46:aa:aa Jan 5 16:30:50 unknown daemon.info dnsmasq-dhcp[12794]: DHCPDISCOVER(br0) 00:09:b0:46:aa:aa Jan 5 16:30:50 unknown daemon.info dnsmasq-dhcp[12794]: DHCPOFFER(br0) 192.168.2.12 00:09:b0:46:aa:aa Jan 5 16:31:13 unknown daemon.info dnsmasq-dhcp[12794]: DHCPDISCOVER(br0) 00:09:b0:46:aa:aa Jan 5 16:31:13 unknown daemon.info dnsmasq-dhcp[12794]: DHCPOFFER(br0) 192.168.2.12 00:09:b0:46:aa:aa Jan 5 16:31:16 unknown daemon.info dnsmasq-dhcp[12794]: DHCPDISCOVER(br0) 00:09:b0:46:aa:aa Jan 5 16:31:16 unknown daemon.info dnsmasq-dhcp[12794]: DHCPOFFER(br0) 192.168.2.12 00:09:b0:46:aa:aa Jan 5 16:31:19 unknown daemon.info dnsmasq-dhcp[12794]: DHCPDISCOVER(br0) 00:09:b0:46:aa:aa Jan 5 16:31:19 unknown daemon.info dnsmasq-dhcp[12794]: DHCPOFFER(br0) 192.168.2.12 00:09:b0:46:aa:aa

Vera is unplugged…

Jan 5 17:11:27 unknown daemon.info dnsmasq-dhcp[12794]: DHCPDISCOVER(br0) 00:09:b0:46:aa:aa Jan 5 17:11:27 unknown daemon.info dnsmasq-dhcp[12794]: DHCPOFFER(br0) 192.168.2.12 00:09:b0:46:aa:aa Jan 5 17:11:27 unknown daemon.info dnsmasq-dhcp[12794]: DHCPREQUEST(br0) 192.168.2.12 00:09:b0:46:aa:aa Jan 5 17:11:27 unknown daemon.info dnsmasq-dhcp[12794]: DHCPACK(br0) 192.168.2.12 00:09:b0:46:aa:aa onkyo

… so I’m thinking if that is the problem (I hope it is) then the Vera is somehow interfering with the discover/request… I have no idea how though.

There is a setting in Access Restriction (which uses MAC) to block DHCP from the Vera. I hope this will block the Vera from interfering… we’ll see.

Interesting. If the DHCP setting you mentioned doesn’t work, you will have to do what I do and manually block DHCP discovery using the router’s firewall. You need to block UDP destination port 67 on packets going to Vera. If Vera doesn’t see any requests it won’t try to respond.

But that will also shut down all of the automatic camera discovery that they built into UI5.

How are you doing it?

I have now blocked ALL ports (TCP & UDP) except: 80, 3480, 49451
… this is allowing the Onkyo to get a DHCP address but something else with the Vera must be interfering with the Onkyo since the Oknyo’s built-in web interface will not respond.

On my router, which is running OpenWrt 10.03.something (actually trunk, but it’s close enough) I’ve got a line like this in my Firewall configuration (see picture).

“lan” and “vera” are two subnets (VLANs) and I don’t allow any traffic to go from vera to lan, but DHCP is different because (some of) it’s going from lan to vera. This line in the config prevents those packets.

On my router, which is running OpenWrt 10.03.something (actually trunk, but it’s close enough) I’ve got a line like this in my Firewall configuration (see picture).

“lan” and “vera” are two subnets (VLANs) and I don’t allow any traffic to go from vera to lan, but DHCP is different because (some of) it’s going from lan to vera. This line in the config prevents those packets.[/quote]

Yeah, I’ve been trying to keep them on the same subnet and use Access Restriction (a nice feature in Tomato firmware) to block communication either from Vera to the LAN (specific ports) or Vera to a specific MAC address. It has worked for DHCP and the Onkyo is getting an IP address BUT once it does for I cannot get to the Onkyo’s web service… I suspect because it is doing something else (like something with uPnP) after it gets its IP and the Vera is hosing that too.

If I keep the Vera unplugged for the first 5 minutes of the Onkyo boot (unplugged → plugged … don’t even need to power it on with Network Standby) then it works fine and I can plug the Vera back in and all are happy.

MCV seems to be ‘looking’ at this on my system but they have not done anything at this point which fixes either the DHCP or uPnP problem.
– I asked them to buy an Onkyo, which can be had for $200, to troubleshoot the issue. I hope they do but I doubt they will.