No announcement yet.
  • Filter
  • Time
  • Show
Clear All
new posts

  • Site to Site issue

    Ok I am at my wits end.

    I am having a problem with making calls site to site.

    1) I have full TCP connectivity.
    2) I have green lights through out Quicklook
    3) Sonicwalls Firewalls have been updated to latest, Sonicwall wall has reviewed settings at said all is OK
    4) If I take a phone from Site B and assign it to Site A (without changing physical location) Phone is unable to call Site B but can call and be called from Site A. And vice versa
    5) UDP port pings to remote (site B) pass through (All shoretel 5000 ports)
    6) Sites are connected via a VPN.
    7) Shoretel has been in and says it is a firewall issue since lsp_ping won;t go through.
    8) Remote site has 90V

    Any questions/suggestions.

  • #2
    Site to Site

    What is your admission control bandwidth set at for both sites?

    You took a phone in site B, assigned it to site A (while physically leaving the phone in site B:

    1. The phone could call and be called from Site A.
    2. The phone could not call or be called from site B (the physical site it was in).

    I may be missing something, but doesn't that rule out most routing and firewall possible issues? You are proving that calls from site A can go to the physical site B? The problem is only when crossing shoretel "logical" "sites"?

    Of course if you can't ping then that does point towards the firewall........

    Are there any events in the event log of the server that might help?


    • #3
      Ok, this might sound like a stupid question but.....

      Do the phones ring at the far end site? Or does nothing happen when you try to call them?


      • #4
        Admission control bandwidth is set to 300 currently but has been set to 900. (just throwng out arbitrary numbers).
        I have also tried with and without DRS.
        No the phone does not ring at far end, there is about a 3-4 second pause then redirects to VM. If transferred from AA then it gets "I'm sorry that extension is unreachable at this time."
        I do believe it would be port 5442 or 5443 that may be the issue. I rule out 5440 as, although I can't do a lsp_ping, I do show switch connectivity.


        • #5
          Possible Solution

          I have had what sounds like the exact same scenario with a Sonic Wall VPN before. Have the Sonic Wall programmers look at the maximum packet size that they are allowing, and push it way up to test and see if that resolves the issue. I do not remember what the magic size was, mostly because we made them leave it high just to be safe.

          Post back if that clears it so I can know,



          • #6
            Actually, they just upgraded the sonicwall so I don't know if this value has changed, I will double check that, but the MTU was maxed at 1500


            • #7
              I'm having this same issue after upgrading Shoretel to 10.1. Was working fine on 7.5. I'm also using Sonicwalls. Did you ever get a resolution and if so could you possibly share.

              Thank you


              • #8
                Definitely looks to be some type of issue with the Sonicwalls. I'm seeing this in the log at my remote site when I attempt to call someone there. Note: my phone is on the switch with IP an the extension I'm calling is on the switch with IP

                06/14/2010 15:59:43.352 Notice Network Access UDP packet dropped, 5441, WAN, 5441, LAN UDP ShoreTel Call Control

                I then called an extension on the switch with IP and get this.

                06/14/2010 16:01:15.864 Notice Network Access UDP packet dropped, 5441, WAN, 5441, LAN UDP ShoreTel Call Control

                If this isn't the cause it sure seems like a mighty big coincidence. Now to see why the Sonicwall is dropping the packet(s)...


                • #9
                  I believe I've got this solved now.

                  At the remote site the the various firewall rules I have setup to allow Shoretel traffic did not have the "Allow Fragmented Packets" box checked. Checking this option appears to have fixed the problem.