0

Issues with STUN server, and registration of Grandstream UCM system

I recently migrated from a Google WiFi system to an Eero. I have a Grandstream UCM6202 system on my network, and it uses plain SIP trunks going to a commercial VoIP provider to give us a home phone (Voip.ms). It's worked fine over the Google Wifi, but the past several months, I've struggled to get it to register with the Eero.

The entire setup is configured according to Voip.ms spec sheet here.

Troubleshooting:
------------------
Eero side: Most of the eero "plus" services are on (advanced security, ad blocking), but I have a profile called "Core Network" setup for all my VoIP ATA's and such that have ad blocking off, and I've also done various other troubleshooting. Example: The Advanced Security has been toggled off to no effect. I've put the specific hostnames in the allow (they didn't seem to be blocked anyway, but just for troubleshooting, I went ahead and tried).

Voip.MS/UCM Side: The setup in Voip.ms is still setup appropriately. The values in the VoIP.ms portal are, too. I regenerated all the passwords, and set them up again and sync'd them on both sides. I've gone through the guide and everything in the UCM is still what it's supposed to be compared to the guide. The darn thing just says "Rejected" but doesn't give me a code. (VoIP.ms isn't even seeing the handshake, so it's not getting that far.)

OK, basics are ok. What about more advanced stuff?

Network side: UCM can see DNS fine from both Eero and Google DNS. No issues. Can perform trace route and ping. No issues. Crap. So, I ran the packet capture in the UCM today. I did a lot of enabling and disabling the trunk to see if I could get any errors (I'm not going to even try doing encrypted until I can get it working unencrypted first). I used WireShark to look at the PCAP file and got what is attached. [See attached photo] The only error in the whole file is that binding request and the reply. And, apparently, it's one of the very few times besides DNS lookups that it's trying to reach outside of the UCM to talk externally.  My guess is that's what's keeping it from successfully completing the rest of the registration.  When I move the network back to the Google Wifi puck, it registers just fine, so it's something the eero is doing/blocking/protecting against.

Can someone explain what's going on here, and provide some guidance? This is next level troubleshooting for me, and I've done a bit of Googling, but it's done nothing more than to introduce confusion - I don't know what I don't know at this point.

1 reply

null
    • hexbus
    • 2 mths ago
    • Reported - view

    Just an update for everyone.

    After spending all day yesterday troubleshooting, I've gotten to the root cause, and been able to repeat the issue consistently.

    After stripping everything down to basics, turning everything OFF that I could, and bringing down the SIP trunk to its most basic level, I got it to work.  This means *everything* was off - all optional services on eero, no TLS or encryption on the SIP trunk, one single SIP trunk, UDP/RTP, etc.

    As I started peeling away and re-enabling things one at a time, there's two services in eero Plus that definitely can cause the issue:

    • Ad Blocking
    • Advanced Security (Note: This service makes my UCM reject the registration of the VoIP trunk even if the UCM is not within scope for ad blocking!  That is strange!)

    The interesting part is that this was a plain UDP/RTP SIP trunk, using port 5060.  Nothing was "suspicious" out this, and it was going to VoIP.ms' many hosts.  

    When I turned these two services OFF, my trunk connected.  When either service on eero is enabled, the trunk  was "rejected".  I did a packet capture on the UCM, and yes, it showed that nothing was getting past the gateway when it attempted to try and send out initial negotiation.  I'm not sure what the eero devices find suspicious about the Grandstream UCM 6200 series device, but it definitely doesn't like them.

     

     

    An interesting thing, too - I can't just toggle these off in the app and then expect the Grandstream to just register the SIP trunk a couple minutes later (and then it automatically works).  I actually have to reboot the UCM, and then it registers just fine.  The software is up to date on these, too.

    Since it's working now, I was able to build the SIP trunk back up and enable SRTP and TLS on it, so it's secure once again, and continues to work fine, as long as Advanced Security and Ad Blocking are turned OFF.  If I turn either of these ON and reboot the UCM, the trunk won't connect - the UCM continues to say "Rejected", and the packet capture does show no negotiation beyond the eero gateway.

    I sent a technical support request with detailed packet captures for both the "Security ON" and "Security OFF" settings to eero and a very detailed explanation of this situation.  It's strange that I should have to turn off this protection for my whole network for a single SIP trunk that is prevented from registering.
     

    So; TLDR:  I'm throwing this up here in case anyone else has an issue with a strange block with something like a VoIP trunk and eero.  Try disabling Advanced Internet Security and Ad Blocking, then reboot your problem device, and see if it works.

Login to reply

Content aside

  • 2 mths agoLast active
  • 1Replies
  • 44Views
  • 2 Following