Announcement

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

  • Director Lost Communication with Switch over VPN

    Shoretel Version 8.1. We have 1 site that is connected to our corproate site via SonicWall VPN. TZ170 on one end and Pro 3060 on the other.

    Up until recently, everything was working fine. We made the change to the sonicwall to use the VPN connection as the default gateway for all traffic. Ever since then, Quick Look shows the site as being Unknows because TMS cannot communicate with the switch. The directory button no longer works at this remote site either. However, call calls flow just fine. I can ping the phone switch from the same server that director is on and vice versa.

    All services are being permitted across the VPN and shoretel stated they could not tell exactly where the communication was failing. They sent us a second switch, we installed it just fine. The switch was recognized by the find switches button, but it also shows as unknown in Director.

    Any ideas on what may be killing this connection? Just for giggles, we changed the configuration back to normal without the default gateway being the VPN tunnel to HQ and it still would not work.

    Thank you in advance.

  • #2
    In the vast majority of the cases, it is the firewall. A lot of firewalls choke up on the traffic being sent and it depends on the particular firewall make as to the fix.

    For example, with Juniper's you need to disable the relevant ALGs and it will work fine.

    Ping will naturally work because it is a layer 3 protocol. Shoretel traffic at layer 7 is quite different (RPC and a combination of other protocols like MGCP and SIP). A good test is to hop on your SG switch at either location and run lsp_ping "IP" from the SG switch to the other switch. This simulates an application specific ping at layer 7. If it fails, the FW is blocking it.

    You'll need to check how Sonicwall handles application layer gateways and adjust according, specifically around MS RPC and MGCP/SIP.

    Comment


    • #3
      I try an ls_ping 192.168.4.11 and it says --> invalid number 192.168.

      Ideas?

      Comment


      • #4
        OOPS.. lsp_ping.. DUH....

        Comment


        • #5
          No dice... that doesn work either..still says invalid number 192.168.

          Comment


          • #6
            I would also try a server reboot if I were you.

            Comment


            • #7
              You need the quotes

              lsp_ping "192.168.41.10"

              Comment


              • #8
                Not sure if related, but which gateway is the switch pointed to?

                Comment


                • #9
                  SG Switch gateway is pointed to the Vlan 4 Interface of the Adtran swtich 192.168.4.1 which then has a default route of the Sonicwall of 10.100.4.2. There is also a route in the sonicwall directing all 192.168.4.x traffic to the 10.100.4.5 default vlan interface of the Adtran switch.

                  Here were a few logs from the firewall.


                  01/28/2010 13:40:53.896 Debug Network TCP packet received on non-existent/closed connection; TCP packet dropped 10.100.0.151, 3370, WAN 192.168.4.11, 4631, LAN TCP Flag(s): RST
                  8 01/28/2010 13:40:53.880 Debug Network TCP connection abort received; TCP connection dropped 10.100.0.151, 3370, WAN 192.168.4.11, 4631, LAN TCP Flag(s): ACK RST


                  Ideas?

                  Comment


                  • #10
                    There is a ANY ANY in the sonicwall for all traffic both directions. Is there some sort of TCP connection setting that may be off?

                    Comment


                    • #11
                      Another log entry....


                      01/28/2010 13:40:23.304 Debug Network TCP connection reject received; TCP connection dropped 192.168.4.11, 1024, LAN 10.100.0.151, 4039, WAN TCP Flag(s): ACK RST

                      Comment

                      Working...
                      X