[Solved] Ooma not working
-
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
-
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 UDPThats from Sys log/firewall/dynamic
Do i make a specific rule just for this somewhere ?
-
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.
-
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.
-
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.
-
This post is deleted! -
Ooma needs those ports outbound not inbound. You shouldn't need any of those ports forwards.
Steve
-
This post is deleted! -
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
-
This post is deleted! -
stephenw10 Netgate Administratorlast edited by stephenw10 Feb 15, 2020, 2:06 PM Feb 15, 2020, 1:46 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
-
@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/
