Today I learned something new, I learned that people have issues when configuring a SonicWALL in front of an MX. This was extremely surprising to me as someone who supports primarily SonicWALL. As I’m configuring a new SonicWALL right now in front of an MX-v -it occurred to me to do a write up and see how well it goes.
Port Triggering - what is this and how does it work?
The most important thing you need to determine is the setup for this system.
Port triggering is a mechanism that is most commonly found in home routers, although I can’t be certain that my use of this term aligns with what the “official” definition is, I’m using it in this case to describe the phenomenon as it makes sense.
- Zultys MX-v sitting behind SonicWALL attempts to register with ITSP (I use Intermedia primarily -more on this later)
- SonicWALL translates the destination port and source port and address before forwarding the traffic outbound (assuming all outbound is open)
- Intermedia responds to the translated Source Port and IP Address
- SonicWALL matches the incoming response to the outbound request from the MX-v and allows the traffic back in
The above example is a classic step by step of what almost every firewall will do out of the box, even with no open inbound ports, the traffic from Intermedia will be allowed due to the initial request starting from inside the network as an outbound request through the SonicWALL. [B]note that exceptions arise when traffic is more strictly regulated[/B] for example, not all outbound traffic is allowed, or an extremely short time-out is configured to the point where you don’t have a continuous uninterrupted conversation between the SIP Provider and the MX-v.
Coming back to Intermedia, they are a Username/Password authentication and happen to have a very quick resubscribe time-out, specifically due to issues with UDP time-outs that they’ve run into, this means that out of the box in a scenario where remote phones are not required and Intermedia is my ITSP I can stick a MX behind the SonicWALL and have zero issues without any firewall changes.
I highly suggest you check with your ITSP -especially if its one that you “standardize” on- and determine the required UDP timeout value
Note if you’re using a provider that is using IP Based Authentication instead of Username/Password Authentication you would need to have ports forwarded for inbound traffic as there’s no guarantee that a previous SIP conversation happened within the timeout period for the traffic to be allowed otherwise
If your provider resubscribe or option packets are sent in longer intervals than your SonicWALL UDP timeout value follow these steps to adjust the timeout on the firewall.
- Identify the outbound port your MX-v will be using to communicate with the ITSP. Intermedia likes to use 6060 for example.
- Login to the SonicWALL and go to Network > Services (Pro-tip if you’re in the new UI of the SonicWALL click on the bottom left corner (three lines) to flip back to the legacy UI which is much easier to find your way around)
- Under “Service Objects” click “Add” and create a new custom service entry, do everyone a favor and name it something that makes sense :D
- Once the Service has been created go to the Firewall > Access Rules and filter from LAN to WAN (note if you’re using a different Zone for the MX change the LAN to the appropriate Zone)
- note that UI changes here happen pretty frequently, if you’re on an older UI you’ll get prompted to choose how you want to view the rules. Select “Drop down” or “Matrix” to allow you to easily drill down into rules relating to LAN to WAN
- the newer UI lists all rules at once, however there are drop downs on the top bar that allow you to filter the “From” and “To” zones
- Click “Add” to create a new Rule using the following information
Source Port: Any
Service: Select the custom service you just created above here
Source: You have the option of choosing ANY here since you’re limiting to a custom service only the MX-v will use, however you can create a custom “Address Object” pointing to the MX-v private IP and select it here.
Destination: You have the option of choosing ANY here since you’re limiting to a custom service only in use by your ITSP however you can create a custom “Address Object” pointing to the ITSP Public IP and select it here.
Keep the rest of the options default and switch over to the “Advanced” tab.
6. The UDP Timeout is listed in seconds and the TCP Timeout is listed in minutes. Intermedia by default sends a resubscribe every 30 seconds which is why it works without additional configurations however if your provider requires a longer interval adjust it on this rule
7. No other options are required here, click “Add” again to save this rule, and make sure it gets created at the top of the list above the default ANY > ANY > ANY > ALLOW rule. You can watch the stats of the rule to make sure the hit count is going up to ensure that the rule is being applied to traffic.
Alright, outbound is easy but what about inbound??
As stated previously, if your ITSP is authenticating by IP and not with an actual registration you should port forward inbound ports on your SonicWALL. Alternatively (or additionally) if you do have remote phones or remote users connecting to your MX-v you will need to have inbound rules created.
The simple most basic port that we generally always port forward on an MX is HTTP Port 80, this is so that the Web Page served by the MX that provides the MX Admin and other download links is available. SonicWALL provides wizards that will allow us to very quickly port forward all the required ports.
- Login to the SonicWALL and on the top right corner select the “Wizards” option.
- Follow the Wizard choosing the “Public Server Wizard” and select the “Web Server” and “HTTP - Port 80” option (if you want 443 as well, select it here).
- For “Server Name” use something descriptive to indicate the MX-v (I’m using Zultys MX-v)
- Specify the Private IP of the MX-v, you can leave the comment blank or you can fill it out and click “Next”
- Specify the Public IP you want to have assigned to the MX-v and click Next
- The summary page will describe everything that will happen when you click “Apply”, go ahead and click that.
You now successfully have generated Firewall and NAT policies for your MX-v that will work on ports 80 and 443 if you selected it. Additionally “Service Groups” have been created that you can use to add additional services into, automatically forwarding those services you add as soon as you include them in the group.
Go back to your Network > Services, this time filter the view to Custom entries only hiding the Default options. Click “Add” to create additional custom services, creating a custom service for any required port.
For simplicity, preface any custom service you create with the same thing -for example Zultys MX-v SIP TLS as 5061 TCP and Zultys MX-v MXAdmin as 7100 TCP this way in the next step you’ll be able to easily select all services without having to go scrolling for it.
Once you have all your services created, flip over to the Service Groups view, and find the custom group “Zultys MX-v Services”. Click on the Pencil or Wrench to edit this group.
Find the new custom services you created and move them all into the group. Click “Ok” to save your changes and all services you just included are now port forwarded to the MX-v. Note that the SonicWALL will automatically create outbound NAT rules from the PBX to the WAN translating the source IP to the Public IP you specified in the Wizard as opposed to the Firewall interface IP when you use the Wizard to create your rules.
Inbound Rules UDP Timeout
My understanding is that lately with the ZIP3x phones and higher this is less of an issue, as stated the default UDP Timeout is 30 seconds, the ZIP3 phones on current firmware are programmed to use option packets that get sent out every 15 seconds. There are advanced configurations you can specify in the phone profile to make sure this is happening and to adjust the time, however if this is an issue you can either create your own custom rule just for the SIP Service (5060 UDP) like you did for the Outbound Custom SIP Service or you can adjust the rule created by the Wizard to change the UDP Timeout. The important thing to keep in mind when creating inbound firewall rules on the SonicWALL that the destination will always be the Translated Public IP not the Private IP.
Edit made thanks to @dslee
Change the Default UDP Timeout to something that makes sense for your ITSP. You can do this under Flood Protection settings, or with specific Access Rules. I prefer Access Rules, inside the allow rule > Advanced > UDP Timeout. You can create allow rules on top of generic Allow rules to be specific and override the UDP Timeout for the specific SIP service.
Ensure under VOIP/Telephony that SIP Transformations are DISABLED and “Enable Consistent NAT” is ENABLED.
This was a lot of typing - and reading: Here’s a bonus
David is not yet a member of this forum, however if he were I would tag him. David is now a member of the forums @deverett! All credit goes to him for the following information as this was shamelessly stolen from his upload to Slack.
Zultys ports.txt - Uploaded to slack
7100-7167 TCP – MXIE/MX Admin
7505 TCP – MXIE/MX Admin
5060 UDP – SIP (phones, ITSP)
5060 TCP – SIP over TCP (if used)
5061 TCP – SIP over TLS (if used)
21000-21039 UDP - MX30 RTP range
21000-21239 UDP – MX250 RTP range
21000-21399 UDP – MX-SE RTP range
21000-24999 UDP - MX-V/MX-E RTP range
69 UDP – TFTP (phone config)
80 TCP - HTTP (MXIE/MX Admin download)
123 UDP - NTP (Time)
443 TCP - HTTPS (phone config)
3306 TCP - MX Report - only if reporting needed remotely
8080 TCP – HTTP (phone config)
7778 TCP - Zultys Mobile, Outlook Communicator, Salesforce, ZAC
7788 TCP - Mobile app push server