DHCP WAN, SIP, states not cleared
-
Running 2.1 Beta (latest snaphot)
I am experiencing the issue (bug) described in this thread:
http://forum.pfsense.org/index.php/topic,18053.0.html
In short. Some states are not cleared when WAN IP is changed.
[Asterisk IP]:5060 -> [Old WAN IP]:5060 -> [SipProvider IP]:5060 MULTIPLE:MULTIPLE
I have tried the different suggested solutions in that thread (and others), but still no luck.
Combinations of pfctl -k [IP] -k [IP] or pfctl -b [IP of SipProvider] will not clear that state.pfctl -F state will stall pfsense and no traffic is routed through WAN->LAN until it is rebooted.
The only thing that works so far is to log in to pfSense webGui->diagnostics->states and kill that particular state, or reset all firewall states. However that is really not an option since it must be done automatically (scripted).
What is the magic with "Reset states" ? Exactly which command is run when the reset button is clicked?
Or the X button to kill a particular state? Those commands must be possible to script.Any help much appreciated, I have run out of options soon.
-
Does pfctl -b [IP] work for you generally?
i.e.
pfctl -ss | fgrep [IP]
pfctl -b [IP]
pfctl -ss | fgrep [IP] -
Result of pfctl -ss | fgrep [SipProvider IP]:
all udp 193.105.226.106:5060 <- 192.168.149.10:5060 MULTIPLE:MULTIPLE
all udp 192.168.149.10:5060 -> [WAN IP]:5060 -> 193.105.226.106:5060 MULTIPLE:MULTIPLEResult of pfctl -b [SipProvider IP]: When executed from ssh shell, the connection is lost. However, if I refresh the "Diagnostics: Show States" with filter on 193.105.226.106 (provider IP), the state is gone.
In the process solving this issue I upgraded from 2.0.1 to latest 2.1 snapshot. I might not have tried pfctl -b on 2.1 before. I think I only tried that one on 2.0.1. I am a bit worried about pfctl -b resetting the ssh connection. It seems like it resets more than the state listed with pfctl -ss | fgrep [SipProvider IP].
I have replaced the pfctl -k[IP] -k[IP] command with pfctl -b [SipProvider IP] to the the "voipstate.sh" script described in the thread http://forum.pfsense.org/index.php/topic,18053.0.html
I 'll get back with results
-
Running pfctl -b [SipProvider IP] within the voipstate.sh script does not solve the problem.
However Running the same command from the command line interface does.I can see that the script captures the IP-change but I have no clue why pfctl -b does not help.
Should the command be called with some special parameter? Or forked out in a separate process?/Nicklas
-
This is related to http://forum.pfsense.org/index.php/topic,18053.0.html which, for some reason, was closed.
C
losing old topics is a horrible policy, it just leads to duplicate threads on the same topic.IMHO this is a major bug in pfsense and nobody seems to care. At least thats what closing the thread indicates.
Also check this out, the state clearing has a fundamental bug (at least in my installation): http://redmine.pfsense.org/issues/2700
-
Threads auto-lock after many months being dead. If the issues is identical, use the report button to ask a moderator to reopen the thread. But on a thread that old (2+ years) a new thread with a reference to the old thread is better since most likely the underlying root cause is not the same given that it was several versions ago.
Auto-locking threads saves a bunch of people trouble in the long run. Old threads are more likely to be fixed or be redundant, there is usually more relevant up-to-date information or they refer to old versions and the current version has been fixed.
-
Also check this out, the state clearing has a fundamental bug (at least in my installation): http://redmine.pfsense.org/issues/2700
That's disappointing …
In your redmine report you write "Unfortunately fixing this still doesn't fix out issue (Asterisk behind pfsense fails to re-register after a WAN loss until state is reset)."
So, in your case, do the 5060 states remain when the WAN IP changes, despite invocation of /usr/local/sbin/ppp-linkdown ? Does manually invoking pfctl -b old_wan_ip/32 clear them ?
-
Also check this out, the state clearing has a fundamental bug (at least in my installation): http://redmine.pfsense.org/issues/2700
That's disappointing …
In your redmine report you write "Unfortunately fixing this still doesn't fix out issue (Asterisk behind pfsense fails to re-register after a WAN loss until state is reset)."
So, in your case, do the 5060 states remain when the WAN IP changes, despite invocation of /usr/local/sbin/ppp-linkdown ? Does manually invoking pfctl -b old_wan_ip/32 clear them ?
No, that did not work. However this seems to be an issue that is very hard fix. Even a pfsense restart sometimes (indeterministic as far as I can tell) will not bring asterisk back to a register-able state.
Even resetting both (pfsense and freepbx/asterisk) sometimes doesn't help. We will next try to stop the asterisk service, reset pfsense and re-enable asterisk.Does anyone have any idea how we can deliver a debug/trace that would help the developers see what is going on. We would very much like to fix this long-standing issue in pfsense because we are otherwise very happy with its quality and features.
-
No, that did not work. However this seems to be an issue that is very hard fix. Even a pfsense restart sometimes (indeterministic as far as I can tell) will not bring asterisk back to a register-able state.
Even resetting both (pfsense and freepbx/asterisk) sometimes doesn't help. We will next try to stop the asterisk service, reset pfsense and re-enable asterisk.Does anyone have any idea how we can deliver a debug/trace that would help the developers see what is going on. We would very much like to fix this long-standing issue in pfsense because we are otherwise very happy with its quality and features.
If resetting all your gear doesn't help, I'm not so sure it's a pfsense issue …
In the past, SIP issues with pfsense were mostly due to its use of symmetric NAT and rewriting of both SIP and RTP ports, however most relatively current software (<3 yr old) employing ICE can deal with that, if not then you'd need to use static-port NAT.
But if you need to troubleshoot VoIP issues beyond the basics, checking SIP software and firewalls & NAT gateways, there can be a huge number of combinations of configuration parameters and intricacies of the various software / firmware involved (e.g. NAT type, UDP timeouts, WAN failover, SIP keepalives, ITSP config etc). Each version of asterisk had its own issues.
Getting VoIP right is much more difficult than let's say running a webserver.
-
No, that did not work. However this seems to be an issue that is very hard fix. Even a pfsense restart sometimes (indeterministic as far as I can tell) will not bring asterisk back to a register-able state.
Even resetting both (pfsense and freepbx/asterisk) sometimes doesn't help. We will next try to stop the asterisk service, reset pfsense and re-enable asterisk.Does anyone have any idea how we can deliver a debug/trace that would help the developers see what is going on. We would very much like to fix this long-standing issue in pfsense because we are otherwise very happy with its quality and features.
If resetting all your gear doesn't help, I'm not so sure it's a pfsense issue …
In the past, SIP issues with pfsense were mostly due to its use of symmetric NAT and rewriting of both SIP and RTP ports, however most relatively current software (<3 yr old) employing ICE can deal with that, if not then you'd need to use static-port NAT.
But if you need to troubleshoot VoIP issues beyond the basics, checking SIP software and firewalls & NAT gateways, there can be a huge number of combinations of configuration parameters and intricacies of the various software / firmware involved (e.g. NAT type, UDP timeouts, WAN failover, SIP keepalives, ITSP config etc). Each version of asterisk had its own issues.
Getting VoIP right is much more difficult than let's say running a webserver.
Believe me, pfSense does not clear SIP states when WAN IP changes. I have tested a lot of configurations and this issue does not occur with OpenWrt or Tomato routers.