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.
