Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Reliably clear SIP UDP states on PPPOE WAN IP change #4652

Closed
2 tasks done
wkochFPV opened this issue Jan 30, 2021 · 6 comments
Closed
2 tasks done

Reliably clear SIP UDP states on PPPOE WAN IP change #4652

wkochFPV opened this issue Jan 30, 2021 · 6 comments
Assignees
Labels
feature Adding new functionality
Milestone

Comments

@wkochFPV
Copy link

Important notices

Before you add a new report, we ask you kindly to acknowledge the following:

Is your feature request related to a problem? Please describe.

These UDP states of SIP clients (phones, gateways and asterisk servers as SIP clients) are not flushed when the WAN IP of PPPOE Dial-Up-Connections (possibly also for DHCP connections, but not tested) changes:

all | udp | 95.118.XXX.XXX:50745 (192.168.3.150:5160) -> XXX.120.186.XXX:5060 | MULTIPLE:MULTIPLE |  
all | udp | 95.118.XXX.XXX:56393 (192.168.3.150:5160) -> XXX.185.37.XX:5060 | MULTIPLE:MULTIPLE |  
all | udp | 95.118.XXX.XXX:43546 (192.168.3.150:5160) -> XXX.10.79.XXX:5060 | MULTIPLE:MULTIPLE |  
all | udp | 95.118.XXX.XXX:22721 (192.168.50.40:5070) -> XXX.185.37.XX:5060 | MULTIPLE:MULTIPLE |  
all | udp | 95.118.XXX.XXX:51082 (192.168.50.10:5060) -> XXX.10.79.XXX:5060 | MULTIPLE:MULTIPLE |  
all | udp | 95.118.XXX.XXX:60499 (192.168.50.20:5060) -> XXX.185.37.XX:5060 | MULTIPLE:MULTIPLE

These stale states leads to all REGISTER (and other) SIP messages remaining unanswered and SIP connectivity of all devices being dropped without possibility for the devices to reconnect. Even after a long time, these entries are not cleared, leading to permanent VOIP connectivity loss.

Manually clearing the entries (via Firewall: Diagnostics: States Dump) resolves the problem immediately.

Enabling "Dynamic state reset" (Firewall: Settings: Advanced) helps to clear these states automatically and allows all SIP clients to reconnect on WAN IP change. Unfortunately, this option clears the entire state table, which would be no problem when using a single WAN interface. Using Multi-WAN, however, this option also interrupts all open connections on all other WAN interfaces. In our setup this kills all RDP remote sessions of home workers and interferes with automated remote backup systems.

Similar problem descriptions:
for OPNSENSE: https://forum.opnsense.org/index.php?topic=10385.0
for PFSENSE (with potential workaround): https://forum.netgate.com/topic/16968/sip-registration-timeout-due-to-stale-entry-in-pfsense-state-table
for PFSENSE: https://redmine.pfsense.org/issues/8

The problem is very common here in Germany: many VDSL PPPOE connections are force closed by the providers once a day to enforce dynamic IP change. Fixed IP is often not available and providers are not willing to disable forced disconnects.

Describe the solution you like

Reliably kill these states on WAN IP change in first place without using "Dynamic state reset" option. Please make sure, this is also done on WAN failover in a multi WAN environment (not tested).

Describe alternatives you considered

None.

Additional context

THANK YOU VERY MUCH FOR YOUR EFFORTS!

Best regards,
Walter

@AdSchellevis AdSchellevis added the support Community support label Jan 30, 2021
@wkochFPV
Copy link
Author

Suggestion for a workaround:
after normal clearing of states check for remaining states (MULTIPLE:MULTIPLE, NAT) containing the old WAN IP and kill those individually with the pfctl -k label -k (or similar) command.

@OPNsense-bot
Copy link

This issue has been automatically timed-out (after 180 days of inactivity).

For more information about the policies for this repository,
please read https://github.com/opnsense/core/blob/master/CONTRIBUTING.md for further details.

If someone wants to step up and work on this issue,
just let us know, so we can reopen the issue and assign an owner to it.

@OPNsense-bot OPNsense-bot added the help wanted Contributor missing / timeout label Aug 11, 2021
@StephanTexxpro
Copy link

The problem still seems to exist in 23.1, please see my report at https://forum.opnsense.org/index.php?topic=32116.0.

@fichtner fichtner reopened this Jan 28, 2023
@fichtner fichtner added feature Adding new functionality and removed help wanted Contributor missing / timeout support Community support labels Jan 28, 2023
@fichtner fichtner self-assigned this Jan 28, 2023
@fichtner fichtner added this to the 23.7 milestone Jan 28, 2023
@fichtner
Copy link
Member

I’ll take it. Some other people require a tweak now that dynamic state reset is gone.

@fichtner
Copy link
Member

fichtner commented Mar 7, 2023

This might be fixed via f57f07997509c in 23.1.2

@fichtner
Copy link
Member

Closing this due to lack of feedback/likely fix a while ago.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
feature Adding new functionality
Development

No branches or pull requests

5 participants