Announcement

Collapse

Welcome to ShoreTelForums.com

Welcome to ShoreTelForums.com!

This site was created as a place to share stories, tips, and troubleshooting help with ShoreTel/Mitel systems. ShoreTel/Mitel is obviously the MOST exciting VoiP platform on the market right now, and we realized there was no centralized place to discuss this platform, but now there is. Please feel free to join and share your experiences.

Please Note: This site IS NOT owned, funded, or managed by ShoreTel/Mitel, Inc. although you may find ShoreTel/Mitel employees sharing there experiences and expertise. If you would like more information on ShoreTel/Mitel systems, contact BTX at [email protected]

As always please support the advertisers that help support our site.

Thank You,
BTX
See more
See less
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • Remote location via Tsunami and Phone Dies after a few minutes

    Originally two phones (IP560) were at a remote location using a MSVPN to connect back into the office without any issues at all. Recently I removed the MSVPN and replaced it with a tsunami point to point wireless link that works flawlessly with everything but the phones.

    The route they take is from the phone through the tsunami point to point link, through a sonicwall and hitting the network the ST switch and server sits on.

    The phone will allow you to place a call anytime you walk up to it and use it. However if you attempt to make a call to it no luck after 5 minutes of placing an outbound call.

    I can ping the phone from the same subnet that it sits on anytime. I can ping a machine that is on the same subnet anytime and can ping the same computer from a remote subnet connected to a different port on the sonicwall anytime.

    I can ping the phone from the remote subnet within 5 minutes of a call being placed from the phone. After that it (the phone) will not accept any inbound calls and I cannot ping it from the remote subnet.

    Any suggestions or recommendations would be appreciated. Thanx!

  • #2
    I guess you've pretty much narrowed it down to sonicwall being the problem. Do you use NAT or PAT? Is phone on the inside and server on the outside?

    Comment


    • #3
      Firewall Timeout

      This is from a Sonicwall Support page:



      This is just a guess, but it sure sounds like what you are seeing. I personally think Sonicwalls are terrible and should be given away to people you hate.

      Caveats
      �� On the Firewall → Advanced page there is a Default Connection Timeout. The Default Connection Timeout value will be used for every rule you create. By default, it is set to 5 minutes. Changing this value will only change the activity timeout for rules added after it is changed. It will not change the value of any previously created rules. SonicWALL recommends keeping this value at 5 minutes and creating specific rules to increase the activity timeout when the service uses static ports.
      When increasing the activity timeout for VPN tunnels, bear in mind that you might need to increase the activity timeout on the LAN to VPN as well as the VPN to LAN rule in order to avoid timeout conditions.
      �� Increasing the activity timeout on access rules increases the time that connections associated with that rule remain open without any activity. This can lead to increased resource consumption, and a possible security risk.
      �� Although it is possible to increase the activity timeout on the default rules (LAN to WAN, LAN to VPN, etc…) instead of writing service specific rules, SonicWALL recommends against this. Increasing the activity timeout on the default rules increases the activity timeout for every connection that is handled by the rules, thereby increasing resource consumption and introducing possible security risks. With services that use dynamic ports, you may have to modify the default rule.

      �� Even though it is possible to allow a service in from the WAN to the LAN (opening a hole), SonicWALL does not recommend doing this. Allowing access this way creates a security risk. SonicWALL recommends creating a VPN tunnel when WAN to LAN access is required. This can be accomplished by using two SonicWALLs or a SonicWALL and SonicWALL’s Global VPN Client.
      Definitions
      �� Activity Timeout – The amount of time without activity before a TCP connection disconnects.
      Before You Begin
      �� Know the service you wish to increase the timeout for. Can you write a service specific rule, or do you need to modify the default rule?
      �� Determine the points of origination and destination for the traffic For example, it is originating from the LAN and destined to a VPN tunnel or WAN.
      �� Decide which address object/group you will use in the rule. Such as LAN Primary Subnet object or LAN Subnets group object
      �� Decide what value you want to make the activity timeout

      Comment


      • #4
        Originally posted by mr-s
        I guess you've pretty much narrowed it down to sonicwall being the problem. Do you use NAT or PAT? Is phone on the inside and server on the outside?
        On the entire network technically both however for this segement of the network neither. Both the phone (remote site) and server / switches sit on the inside on different ports of the sonicwall with of course different subnets.

        Comment


        • #5
          Originally posted by eazeaz
          This is from a Sonicwall Support page:



          This is just a guess, but it sure sounds like what you are seeing. I personally think Sonicwalls are terrible and should be given away to people you hate.

          Caveats
          �� On the Firewall → Advanced page there is a Default Connection Timeout. The Default Connection Timeout value will be used for every rule you create. By default, it is set to 5 minutes. Changing this value will only change the activity timeout for rules added after it is changed. It will not change the value of any previously created rules. SonicWALL recommends keeping this value at 5 minutes and creating specific rules to increase the activity timeout when the service uses static ports.
          When increasing the activity timeout for VPN tunnels, bear in mind that you might need to increase the activity timeout on the LAN to VPN as well as the VPN to LAN rule in order to avoid timeout conditions.
          �� Increasing the activity timeout on access rules increases the time that connections associated with that rule remain open without any activity. This can lead to increased resource consumption, and a possible security risk.
          �� Although it is possible to increase the activity timeout on the default rules (LAN to WAN, LAN to VPN, etc…) instead of writing service specific rules, SonicWALL recommends against this. Increasing the activity timeout on the default rules increases the activity timeout for every connection that is handled by the rules, thereby increasing resource consumption and introducing possible security risks. With services that use dynamic ports, you may have to modify the default rule.

          �� Even though it is possible to allow a service in from the WAN to the LAN (opening a hole), SonicWALL does not recommend doing this. Allowing access this way creates a security risk. SonicWALL recommends creating a VPN tunnel when WAN to LAN access is required. This can be accomplished by using two SonicWALLs or a SonicWALL and SonicWALL’s Global VPN Client.
          Definitions
          �� Activity Timeout – The amount of time without activity before a TCP connection disconnects.
          Before You Begin
          �� Know the service you wish to increase the timeout for. Can you write a service specific rule, or do you need to modify the default rule?
          �� Determine the points of origination and destination for the traffic For example, it is originating from the LAN and destined to a VPN tunnel or WAN.
          �� Decide which address object/group you will use in the rule. Such as LAN Primary Subnet object or LAN Subnets group object
          �� Decide what value you want to make the activity timeout

          Currently I have no limitations and both ports on the sonicwall are allowed to pass all traffic between the two. Played around with these other recommendations with no success yet. What is interesting is if I put a static ARP entry of the phone into the sonicwall the ping is successful and will not time out at all but the phone receives no service.

          Also the shoreware director is reporting a different MAC address then the sonicwall and other devices are. Is there a reason for this? I did double check to make sure I was correct on which device I was looking at.

          Comment


          • #6
            Timeout

            Even still, don't you think that it is REALLY fishy that the default sonicwall timeout is 5 minutes and you are timing out after 5 Minutes?

            Silly question, but I assume you have tried to power down the firewall and restart it? I have seen sonicwalls report certain configurations but not REALLY be using them...

            Can you look at the logs on the sonicwall? I would bet that you could see the packets being denied for xxxxxx reason.
            Last edited by eazeaz; 12-28-2007, 01:15 PM.

            Comment


            • #7
              Originally posted by eazeaz
              Even still, don't you think that it is REALLY fishy that the default sonicwall timeout is 5 minutes and you are timing out after 5 Minutes?

              Silly question, but I assume you have tried to power down the firewall and restart it? I have seen sonicwalls report certain configurations but not REALLY be using them...

              Can you look at the logs on the sonicwall? I would bet that you could see the packets being denied for xxxxxx reason.
              I 100% agree that it is very odd that the default sonicwall timeout is 5 which matches what i am getting. I have restarted the SW and have been looking at the logs. I think im going to take the sonicwall out the equation with another device for now just to verify it is it.

              Thanx for everyones replies!

              Comment

              Working...
              X
              😀
              🥰
              🤢
              😎
              😡
              👍
              👎