Michael, You stated the qualify yes/no tradeoffs perfectly.
Personally I would use "no" if it is not needed, but if you like the latency check give "yes" a shot - the chance of messing-up a firewall state along the way should be low. Lonnie On Dec 18, 2017, at 7:37 PM, Michael Knill <michael.kn...@ipcsolutions.com.au> wrote: > Thanks Lonnie > > Is there a reason why I would turn off qualify? Its kind of nice knowing > whether your ITSP peer is up and it also can highlight potential network > issues when you start getting lags and unreachables! > > But if there is a risk of it messing with the Firewall state then it may be > worth doing. > > 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 11:50 am > To: AstLinux List <astlinux-users@lists.sourceforge.net> > Subject: Re: [Astlinux-users] Problems with PPPoE and Asterisk > > Hi Michael, > > My commercial SIP provider offers exactly the scenario I suggested, using > static IPv4 authentication as you are doing. > > I used the same suggested setup for a dynamic remote trunk for years ... > until I switched it to WireGuard a few weeks ago. Though it was a dynamic > cable modem, not PPPoE. > > But, if you are having the same PPPoE issue with a commercial SIP provider, > for your clients trying "qualify=no" and opening UDP 5060 from your IPv4 > server host would be worth a try. > > Though going forward, if the server's IP changes you will have more editing > to do for each remote client. > > Lonnie > > > On Dec 18, 2017, at 6:11 PM, Michael Knill > <michael.kn...@ipcsolutions.com.au> wrote: > >> Hi Lonnie >> >> In this case it is an Astlinux box at the other end but I also have issues >> with SIP Trunk providers that I have no administrative control over. >> Interestingly I don't think this happens when you lose the PPPoE through >> network or Layer 1 issues. For this one it was LCP terminated by Peer which >> may do something differently. >> >> I was thinking therefore of adding a 5060 firewall rule for all my clients >> using the SIP Provider address ranges. Do you think that may solve this >> issue e.g. the firewall rule is static and not dynamic? >> Virtually all my systems have a static IP. >> >> 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 9:22 am >> To: AstLinux List <astlinux-users@lists.sourceforge.net> >> Subject: Re: [Astlinux-users] Problems with PPPoE and Asterisk >> >> 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. >> >> >> ------------------------------------------------------------------------------ >> 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. >> >> > > > ------------------------------------------------------------------------------ > 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. > > > ------------------------------------------------------------------------------ > 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. > > ------------------------------------------------------------------------------ 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.
