Hi Michael, What you are currently doing works *almost* all the time, but there seems to be edge conditions when the PPPoE link cycles.
If you don't need the server end "qualify=yes" to monitor the latency and/or immediate "channel not available" (which can also cause issues) ... I would consider "qualify=no" at the server end and add a UDP 5060 firewall rule for each remote static IPv4 SIP client. This also documents the SIP endpoints, easily disable one at the network level, etc. . Additionally, if the remote SIP clients are dynamic (w/ Dynamic DNS Update) and register with asterisk to authenticate, at the server end you can use the AIF dyndns-host-open plugin and define -- DYNDNS_HOST_OPEN_UDP="remote1.sip.tld~5060 remote2.sip.tld~5060" -- for every remote dynamic client. In all cases the remote SIP clients (static or dynamic) are configured with "qualify=yes" at the remote end to open their firewall. Possibly you can test with one trunk and see if it helps. Lonnie On Dec 18, 2017, at 3:23 PM, Michael Knill <michael.kn...@ipcsolutions.com.au> wrote: > Awesome sipgrep! I keep finding new tools all the time that I wished I knew > about earlier. Maybe we should have a helpful Astlinux tools page one day. > > Both ends use qualify (SIP OPTIONS) so the firewall state should always > remain open but do you think that adding a static rule in the firewall more > reliable? > I was thinking of doing this for all my systems for security purposes but it > may also remove the reliance on the firewall setting up dynamic states! > > Regards > Michael Knill > > -----Original Message----- > From: Lonnie Abelbeck <li...@lonnie.abelbeck.com> > Reply-To: AstLinux List <astlinux-users@lists.sourceforge.net> > Date: Tuesday, 19 December 2017 at 1:54 am > To: AstLinux List <astlinux-users@lists.sourceforge.net> > Subject: Re: [Astlinux-users] Problems with PPPoE and Asterisk > > Hi Michael, > >> The terminating SIP server is actually another Astlinux box. > > Cool, so this should be solvable. > > Yes, as you suggested a sip debug on the Asterisk CLI (or use "sipgrep") > would help ... if you can VPN into the server also a help during the failure. > > I would try setting qualify=yes to only the client end SIP trunk, not the > server end, this would consistently establish new firewall states from the > client to the server endpoint. I'm assuming the client end does not open UDP > 5060 and relies on the outbound SIP OPTIONS traffic to establish the firewall > state. > > Additionally, since your SIP trunk is authenticating on the static IPv4 > address of the PPPoE endpoint, make sure that IPv4 address is indeed static > during any PPPoE hiccups. > > Lonnie > > PS, this is a perfect scenario for placing the SIP trunk over a WireGuard > VPN, for your future setup down the road :-) > > > > On Dec 17, 2017, at 10:56 PM, Michael Knill > <michael.kn...@ipcsolutions.com.au> wrote: > >> Hi Lonnie >> >> No it's an IP Address only SIP Trunk so no registration. Only Options Pings. >> I should have done a sip debug on the Asterisk CLI I think. >> It's a static local IP Address (passed by PPPoE) and it did not change. >> The terminating SIP Server has a single Public IP Address so there should be >> no NAT but I cannot guarantee. The terminating SIP server is actually >> another Astlinux box. >> >> Im just wondering; if no IP Address or Port had changed, shouldn't the >> firewall state remain the same anyway? >> >> I will try that. More testing required! >> >> Regards >> Michael Knill >> >> -----Original Message----- >> From: Lonnie Abelbeck <li...@lonnie.abelbeck.com> >> Reply-To: AstLinux List <astlinux-users@lists.sourceforge.net> >> Date: Monday, 18 December 2017 at 3:39 pm >> To: AstLinux List <astlinux-users@lists.sourceforge.net> >> Subject: Re: [Astlinux-users] Problems with PPPoE and Asterisk >> >> Hi Michael, >> >> I see your logs stopped after the PPPoE connection was reestablished. Are >> there a bunch of asterisk register timeouts after that point ? >> >> Does your PPPoE "local IP address" typically change every time the >> connection goes down and back up ? >> >> This does sound like a firewall invalid state issue and rebooting allows the >> invalid state's TTL to expire, BUT the firewall state is probably not in >> AstLinux but rather upstream. >> >> Is it possible there is NAT in the path between your PPPoE "local IP >> address" and the SIP server ? >> >> Does the remote SIP server resolve to a single IPv4 address, or is it a >> round-robin of IPv4 addresses ? >> >> >>> Yes I agree. I think it's a firewall problem although a Restart Firewall >>> did not fix it ( >>> Can you think of any good debugging I can do if it happens again? >> >> The next time, rather than rebooting, I would try from the CLI ... >> -- >> service asterisk stop >> (wait 3 minutes or more - use your watch) >> service asterisk init >> -- >> If that re-establishes SIP connectivity, that would imply the >> stuck-firewall-state was upstream. >> >> Lonnie >> >> >> >> On Dec 17, 2017, at 4:43 PM, Michael Knill >> <michael.kn...@ipcsolutions.com.au> wrote: >> >>> Hi Group >>> >>> I am still having issues with PPPoE and Asterisk connectivity. >>> >>> This happened over the weekend with one of my sites: >>> Dec 17 00:30:09 2005-Shaw_BG-CM1 local0.notice asterisk[1266]: >>> NOTICE[1408]: chan_sip.c:30077 in sip_poke_noanswer: Peer 'cts_trunk' is >>> now UNREACHABLE! Last qualify: 33 >>> Dec 17 00:30:33 2005-Shaw_BG-CM1 local0.notice asterisk[1266]: >>> NOTICE[1408]: chan_sip.c:24558 in handle_response_peerpoke: Peer >>> 'cts_trunk' is now Reachable. (34ms / 2000ms) >>> Dec 17 00:30:52 2005-Shaw_BG-CM1 daemon.info pppd[336]: LCP terminated by >>> peer >>> Dec 17 00:30:52 2005-Shaw_BG-CM1 daemon.info pppd[336]: Connect time 568.6 >>> minutes. >>> Dec 17 00:30:52 2005-Shaw_BG-CM1 daemon.info pppd[336]: Sent 1190012 bytes, >>> received 1282467 bytes. >>> Dec 17 00:30:55 2005-Shaw_BG-CM1 daemon.notice pppd[336]: Connection >>> terminated. >>> Dec 17 00:30:55 2005-Shaw_BG-CM1 daemon.notice pppd[336]: Modem hangup ------------------------------------------------------------------------------ Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot _______________________________________________ Astlinux-users mailing list Astlinux-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/astlinux-users Donations to support AstLinux are graciously accepted via PayPal to pay...@krisk.org.
