Issues resetting states
-
Hello everyone - I just recently upgraded my firewall appliance from an SG-1000 to an SG-3100. My SIP trunk provider Vitelity, made a change recently for RTP ports. They changed from ports 10000-36385. I have updated the settings to reflect the new RTP port range and want to reset my states but it doesn't look like the states are actually resetting. When I go to Diagnostic > States > Reset States
I check the box that says "Reset the firewall state table" and then click Reset but nothing happens. I've tried using two different browsers (Chrome and Edge) but both have issues. After I click "Reset" there is a message that pops up saying "Do you really want to reset the selected states" in which I click "ok".
After that, nothing happens at all. I can see the address bar within the browser is spinning as if something was happening but the browser never refreshes and I'm back to square one.
Is there a way to reset the states from ssh console? When I ssh into the console I get the following entries but none are for resetting the state.
- Logout (SSH only) 9) pfTop
- Assign Interfaces 10) Filter Logs
- Set interface(s) IP address 11) Restart webConfigurator
- Reset webConfigurator password 12) PHP shell + Netgate pfSense Plus tools
- Reset to factory defaults 13) Update from console
- Reboot system 14) Disable Secure Shell (sshd)
- Halt system 15) Restore recent configuration
- Ping host 16) Restart PHP-FPM
- Shell
-
@jkalber
It happens, but it also breaks the state to your management console. After you Reset, click to the States tab to reconnect your session. -
@provels Just so I am understanding correctly, I should be doing the following?
1.) Click Reset
2.) With the same tab opened, click Diagnostic and then click States?
When I do that, nothing happens. The GUI is still stuck on the reset states window with my browser spinning/hung up.
-
-
@provels I get that it happens but is it supposed to happen every single time I reset states? Does the GUI never refresh/load saying something like "states reset successfully" or something of that nature? I noticed that the RTP setting was set to 10000-20000 which were the previous "recommended" settings from Vitelity. I adjusted the RTP port range to 10000-36385 and went to reset the states but just want to confirm that they reset successfully. I could have sworn last time I did this, the browser eventually refresh/loaded with a message that the states were reset successfully. I'm having a weird issue with outbound calls - once the call connects (someone answers the phone on the other end) the call goes silent for my employees. This was previously fixed with setting the RTP port range from 10000-20000 to 10000-36385 but I always had to reset the states after I made that change.
-
@jkalber said in Issues resetting states:
Does the GUI never refresh/load saying something like "states reset successfully" or something of that nature?
Not in my experience.
Monitor your live FW logs for all traffic for a selected phone's IP to see if you're blocking it somehow. Sounds like it may be switching to another range after call pickup. Not a VOIP expert. Hated VOIP when I had to maintain it.
-
@provels Yeah - it can be a real pain in the butt to support and manage sometimes.
-
So Vitelity believes I have an issue with the firewall and how it is handling port forwarding. Are there any experts here that might be able to help me out? I have all of our firewalls configured the same for RTP port forwarding, not sure if there is anywhere else that I can check to resolve this issue?
From Vitelity: I believe I have identified the issue. I have uploaded a SIP ladder for your review. As I was capturing the call I could hear the called party answered and say hello a couple times and the calling party said they couldn't hear anything. I believe the issue is with your RTP ports. Your invite specifies that you want us to send RTP to 216.74.234.162 port 34502 in the SDP, but when you're sending us audio, you're sending it from port 12002. When we send you audio, we send it to 34502 as you requested. I confirmed this same behavior on multiple calls. My best guess is that it's an issue with how your firewall is handling the port forwarding.
-
@jkalber
I remember we had issues with one-way audio, but too many years ago now. I'd probably make a couple LAN rules to monitor ALL traffic to/from a test phone's IP and also your phone server's IP, then monitor the FW logs dynamically and filter the logs for the related IPs and test, test, test. If that doesn't find it, move to the WAN. Sorry, best I can offer. -
@jkalber said in Issues resetting states:
but when you're sending us audio, you're sending it from port 12002
That sounds like the NAT is changing the ports. You can give the phone a fixed IP and tell pfSense not to do that:
Navigate to “Firewall” > “NAT” > “Outbound”.
Set the type from automatic to “Hybrid” and press “Save”.
Now create a new “Mapping Rule” to set:
“Source” for the phone LAN IP, e.g. 192.168.3.155.
“Port or Range” - enable “Static Port”.Move the rule to the first position in your “Mappings" table.
It probably depends on the phone and phone system? We host 3CX for clients and though only one has a phone using STUN we haven't had to do that for the phone. But it's necessary if the 3CX server is behind NAT.
-
@steveits Thanks for the recommendation Steve! So I already have the NAT mode set to Hybrid Outbound NAT just like every other site that I support. I haven't had to create any type of mapping rule to specify a phones static IP, thoughts?
Below is a screenshot of my current settings for NAT Outbound
-
@jkalber That's saying all devices on your network using UDP get a translated port. If you check Static Port what happens? You might need to clear states for the phone or reboot the phone, if it doesn't work right away.
-
@steveits Are you referring to the check box that says Static Port right next to Port or Range which I currently have blank?
-
@steveits HOLY CRAP THAT WAS IT. Dude can you shoot me your venmo or zelle? I owe you a six pack at the very least.
-
@jkalber You're welcome. Just help someone else someday. :)