Netgate Discussion Forum
    • Categories
    • Recent
    • Tags
    • Popular
    • Users
    • Search
    • Register
    • Login

    [Solved] Ooma not working

    Scheduled Pinned Locked Moved General pfSense Questions
    50 Posts 5 Posters 8.1k Views
    Loading More Posts
    • Oldest to Newest
    • Newest to Oldest
    • Most Votes
    Reply
    • Reply as topic
    Log in to reply
    This topic has been deleted. Only users with topic management privileges can see it.
    • X
      x88dually
      last edited by 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.

      1 Reply Last reply Reply Quote 0
      • stephenw10S
        stephenw10 Netgate Administrator
        last edited by

        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

        1 Reply Last reply Reply Quote 0
        • X
          x88dually
          last edited by 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 ?

          1 Reply Last reply Reply Quote 0
          • X
            x88dually
            last edited by

            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.

            1 Reply Last reply Reply Quote 0
            • stephenw10S
              stephenw10 Netgate Administrator
              last edited by

              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.

              1 Reply Last reply Reply Quote 0
              • X
                x88dually
                last edited by 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.

                D 1 Reply Last reply Reply Quote 0
                • D
                  Deens @x88dually
                  last edited by Deens

                  This post is deleted!
                  1 Reply Last reply Reply Quote 0
                  • stephenw10S
                    stephenw10 Netgate Administrator
                    last edited by

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

                    Steve

                    D johnpozJ 2 Replies Last reply Reply Quote 0
                    • D
                      Deens @stephenw10
                      last edited by

                      This post is deleted!
                      1 Reply Last reply Reply Quote 0
                      • stephenw10S
                        stephenw10 Netgate Administrator
                        last edited by

                        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

                        D 1 Reply Last reply Reply Quote 0
                        • D
                          Deens @stephenw10
                          last edited by Deens

                          This post is deleted!
                          1 Reply Last reply Reply Quote 0
                          • stephenw10S
                            stephenw10 Netgate Administrator
                            last edited by 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

                            1 Reply Last reply Reply Quote 0
                            • johnpozJ
                              johnpoz LAYER 8 Global Moderator @stephenw10
                              last edited by johnpoz

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

                              outbound.jpg

                              An intelligent man is sometimes forced to be drunk to spend time with his fools
                              If you get confused: Listen to the Music Play
                              Please don't Chat/PM me for help, unless mod related
                              SG-4860 24.11 | Lab VMs 2.8, 24.11

                              1 Reply Last reply Reply Quote 0
                              • First post
                                Last post
                              Copyright 2025 Rubicon Communications LLC (Netgate). All rights reserved.