[Solved] Ooma not working

chpalmer

Looks like the device connects via a VPN..

https://support.ooma.com/home/problems-connecting-to-setup-ooma-com/

Follow this and see. You have to plug into their port.

chpalmer

Setup static port on your OOma device address.

Instead of port 5060 in this article do it for port 1194

https://docs.netgate.com/pfsense/en/latest/nat/configuring-nat-for-voip-phones.html#disable-source-port-rewriting

stephenw10

OpenVPN shouldn't care about the source port. If they have broken OpenVPN that's an achievement!

However it won't connect at if it's not pulling a DHCP lease. The logs you showed seem to indicate it did pull an IP assuming your have confirmed 00:18:61:2e:8e:7f is the Ooma device?
Does it show a current lease in Status > DHCP Leases?

Check the states it has opened. Go to Diagnostics > States and filter using it's IP address, 10.15.15.2 if it has not changed.
Show us what states are open for that if any.

Steve

chpalmer

@stephenw10 said in Ooma not working:

OpenVPN shouldn't care about the source port. If they have broken OpenVPN that's an achievement!

Im trying to remember but I believe this would not be the first time someone did..

stephenw10

Ha, well I could certainly believe that! But OpenVPN is what you choose when your device has to be able to plug into any router and connect out as Oooma does. If they broke the server end so it required a static port that would be some spectacular foot-shooting.
It would also limit them to just one device per public IP which seems like a bad decision.

Steve

chpalmer

@stephenw10 said in Ooma not working:

It would also limit them to just one device per public IP which seems like a bad decision.

Many VOIP providers skirt this by sequentially numbering the ports. My phone uses 5060, 5062 and 5064 for my three lines right here.

My guess is that if someone wanted more than one OOma device at their house then support would do something similar with their VPNs. I wonder how many do though. Or how many lines that OOma device can do?? two or possibly three depending.

There is a saying that a Ford engineer will step over 20 hookers to screw a mechanic.. Sometimes I believe the same about software and system engineers and IT personnel..

x88dually

still working on all this and nothing.
made a few rules but no clue if theyre right.

think i'm giving up for the night

x88dually

on ooma, i can forward a port, but its 5060 to port 80 om device

x88dually

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

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

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

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

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

This post is deleted!

stephenw10

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

Steve

Deens

This post is deleted!

stephenw10

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

This post is deleted!

stephenw10

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