[Solved] Ooma not working

x88dually · Jan 14, 2020, 3:01 AM

ok, Ooma ip isn't showing in diag/states/Wan or in its own Lan. But, roku and fireTv's show up in both logs, So WTF ?? The device shows its got an internet connect, but no vpn or tunnel. And i changed it to static ip on device. But old or new ip, neither shows up in logs i already said and checked.

Think i'm gonna call it a night now.

Thx for the help so far.

stephenw10 · Jan 14, 2020, 11:29 AM

Hmm, well if it's getting an IP but not opening any states then it's either just not trying to connect or being blocked.

Check Status > System Logs > Firewall for any blocked traffic from the Ooma IP.

Ultimately running a packet capture in Diag > Packet Capture on the interface it's connected to and filtered by it's IP.
That will show you what it's doing, if anything.

Steve

x88dually · Jan 14, 2020, 4:34 PM

Jan 14 11:28:38	LAN	10.15.15.02:45652	208.83.246.199:443	TCP:S
Jan 14 11:28:36	WAN	[fe80::1daf:bef0:18ce:e5be]:56059	[ff02::c]:1900	UDP
Jan 14 11:28:32	WAN	[fe80::1daf:bef0:18ce:e5be]:56059	[ff02::c]:1900	UDP
Jan 14 11:28:29	WAN	[fe80::1daf:bef0:18ce:e5be]:56059	[ff02::c]:1900	UDP
Jan 14 11:28:26	WAN	[fe80::1daf:bef0:18ce:e5be]:56059	[ff02::c]:1900	UDP
Jan 14 11:28:22	WAN	[fe80::1daf:bef0:18ce:e5be]:56059	[ff02::c]:1900	UDP
Jan 14 11:28:21	LAN	10.15.15.02:45652	208.83.246.199:443	TCP:S
Jan 14 11:28:19	WAN	[fe80::1daf:bef0:18ce:e5be]:56059	[ff02::c]:1900	UDP
Jan 14 11:28:16	WAN	[fe80::1daf:bef0:18ce:e5be]:56059	[ff02::c]:1900	UDP
Jan 14 11:28:14	LAN	10.15.15.02:45652	208.83.246.199:443	TCP:S
Jan 14 11:28:12	WAN	[fe80::1daf:bef0:18ce:e5be]:56059	[ff02::c]:1900	UDP
Jan 14 11:28:10	LAN	10.15.15.02:45652	208.83.246.199:443	TCP:S
Jan 14 11:28:09	WAN	[fe80::1daf:bef0:18ce:e5be]:56059	[ff02::c]:1900	UDP
Jan 14 11:28:08	LAN	10.15.15.2:45652	208.83.246.199:443	TCP:S
Jan 14 11:28:07	LAN	10.15.15.2:45652	208.83.246.199:443	TCP:S
Jan 14 11:28:06	WAN	[fe80::1daf:bef0:18ce:e5be]:56059	[ff02::c]:1900	UDP

Thats from Sys log/firewall/dynamic

Do i make a specific rule just for this somewhere ?

x88dually · Jan 14, 2020, 4:43 PM

i think i'm goin back to the beginning. 1 lan, everything on the same subnet, i'm gettin confused.

Gimme a few hours please.

stephenw10 · Jan 14, 2020, 4:55 PM

Unclear if those are blocks but if they are and 10.15.15.2 is the Ooma device then it looks like it's connecting on LAN (should it be?) and is being blocked for outbound TCP.

x88dually · Jan 14, 2020, 5:19 PM

WTF ??!!

It works now

I had ooms goin out thru router(cisco rv325). Changed it to pfsense (lan, for now),, and now its connected and working.

Deens · Feb 14, 2020, 8:46 PM

This post is deleted!

stephenw10 · Feb 14, 2020, 1:59 PM

Ooma needs those ports outbound not inbound. You shouldn't need any of those ports forwards.

Steve

Deens · Feb 14, 2020, 8:51 PM

This post is deleted!

stephenw10 · Feb 14, 2020, 10:19 PM

OpenVPN is definitely not required inbound. The server never connects to the client. The client connects outbound to the server only.
The service is expected to 'just work' behind any random router. They cannot possibly expect the average user to setup a whole bunch of port forwards. At most they might require UPnP so the device can set them up itself but I don't see any mention of that.

Steve

Deens · Feb 15, 2020, 12:56 PM

This post is deleted!

stephenw10 · Feb 15, 2020, 2:06 PM

Outbound NAT should be enabled by default for all traffic from an internal device like that. You should not need any additional outbound NAT rules. The only exception to that would be something that requires a static source port, which some VoIP devices do, but this is not using SIP so it's unlikely.

It's not about traffic both ways, which is obviously required. In a stateful firewall it's about how the connection is opened. All connections from the LAN are allowed out so the Ooma is able to connect out to check for firmware updates. Reply traffic from the firmware server is allowed back because the firewall state is now open.
The same is true for the OpenVPN connection. The client in the Ooma connects out to the server and replies from the server are now allowed back to it so the tunnel is established.

https://docs.netgate.com/pfsense/en/latest/book/firewall/firewall-fundamentals.html#stateful-filtering

Steve

johnpoz · Feb 15, 2020, 1:56 PM

@stephenw10 said in [Solved] Ooma not working:

You shouldn't need any of those ports forwards.

Exactly - says right on their site, these are "outbound" ports

https://support.ooma.com/home/advanced-connections-and-service-ports/

login-to-view