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

    ShoreTel Switch-To-Switch over IPsec on pfSense - not working

    Scheduled Pinned Locked Moved IPsec
    5 Posts 3 Posters 484 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.
    • S
      STLscott314
      last edited by

      Hi and thanks for reading.

      I have two ShoreTel phone switches, one in Seattle and one in St. Louis. Previously bridged with a SonicWall IPsec VPN. I've replaced the SonicWall on both ends with a pfSense+ Virtual running 23.05 in St. Louis and a NetGate 3100 running 23.05 in Seattle. I have a standard IPsec VPN Bridge in Tunnel mode, nothing fancy. This was a drop-and-insert from the SonicWall. The phone switch in St. Louis and the Switch in Seattle will not talk to each other (shows as offline). The issue is that there is a T1 in St. Louis that feeds the St. Louis ShoreTel switch with Dialtone. The Switch in Seattle gets its Dialtone from our St. Louis T1 over the VPN bridge, which now doesn't work. Also, phone extensions in Seattle can't call extensions in St. Louis since the new firewall/VPN install. I have rules in place on both firewalls that allow ALL traffic on either side to either side. I have rules on LAN adapters on either side to access all traffic on the opposite sides. The tunnel is working perfectly. I can ping anything from/to either side, I can ping with MTU up to 1470. I can remote into the switch in Seattle over the bridge (SSH), I can print from St. Louis to Seattle and vice-versa, I can RDP from St. Louis to Seattle, I can configure the firewall in Seattle over the VPN bridge. I can access shares over the VPN. Everything works except this ShoreTel issue. I've had ShoreTel working on this issue for weeks and they keep telling me that it's something in the firewall that is blocking or not routing. The pfSense firewall on both sides is the default gateway for everything on each side, so there is nothing fancy here. It's like the new VPN is blocking whatever handshake occurs on the ShoreTel side. Anyone with extensive knowledge of the ShoreTel communication would be so helpful. Just to be clear, our ShoreTel/VOIP traffic all runs over the IPsec tunnel. There is no cloud sip provider in the mix. All of the articles I've found are about issues going out to the cloud or coming back from the cloud, that is not how this is configured. This is all private-cloud over IPsec. Any help would be greatly appreciated.

      Thanks
      Scott20230627_143017.jpg

      R keyserK 2 Replies Last reply Reply Quote 0
      • R
        rcoleman-netgate Netgate @STLscott314
        last edited by

        @STLscott314 said in ShoreTel Switch-To-Switch over IPsec on pfSense - not working:

        I've had ShoreTel working on this issue for weeks and they keep telling me that it's something in the firewall that is blocking or not routing. The pfSense firewall on both sides is the default gateway for everything on each side, so there is nothing fancy here.

        Run packet captures on either side of the tunnel. Make sure you have the traffic going out the IPsec on the remote side and coming in on the HQ side.

        Then trace the packets (with more pcaps) to the interface it traverses to the ShorTel HQ. If the traffic comes out that interface but does not return -- the issue is with the ShoreTel.

        If it doesn't get there then you have a route issue somewhere.

        Ryan
        Repeat, after me: MESH IS THE DEVIL! MESH IS THE DEVIL!
        Requesting firmware for your Netgate device? https://go.netgate.com
        Switching: Mikrotik, Netgear, Extreme
        Wireless: Aruba, Ubiquiti

        S 1 Reply Last reply Reply Quote 0
        • keyserK
          keyser Rebel Alliance @STLscott314
          last edited by

          @STLscott314 @rcoleman-netgate Suggestion is obviously the first thing you should do, because your issue really does sound like a routing/gateway problem. Apart from that it does seem strange as the setup is very simple as described.
          The only “freak” thing I can think of is if Scrubbing is causing issues (never tried that myself before). Try and disable PF scrubbing:
          df701149-2593-40c3-a111-90647ff9dd4e-image.png

          Love the no fuss of using the official appliances :-)

          S 1 Reply Last reply Reply Quote 0
          • S
            STLscott314 @keyser
            last edited by

            @keyser

            Thanks for that suggestion, I had already disabled Firewall Scrub on both sides, forgot to mention that. I saw that check-marked when I went to double check after your suggestion.

            1 Reply Last reply Reply Quote 0
            • S
              STLscott314 @rcoleman-netgate
              last edited by

              @rcoleman-netgate
              Thank you for the suggestion, Unfortunately, this is way out of my knowledge base (doing packet captures, other than on the firewall) and then definately out of my knowledge base on reading pcaps. What should I use to capture packets on the remote side when the devices are not friendly with that? I'm in St. Louis, the "remote end" is in Seattle. The ShoreTel switch in Seattle doesn't provide that capability (not that I can find/document) nor do the ShoreTel ip phones. I have a notebook computer there running Windows 10 but the network switch is not managed so there's no pervasive mode option (just a layer-2 Linksys switch). I provided PCAPs from the firewall to ShoreTel and they said there was no "RTP traffic" coming over the IPSEC tunnel from Seattle to St. Louis and claim it's network/routing issue. The ShoreTel switch does not provide any routing capabilities, it just has a default gateway setting, which is set to the pfSense firewall.

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