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.
