Thanks Neil. Fortunately I still have access to this most recent SonicWALL box remotely via the backup ADSL interface. I've attached a .pcap trace file from the PPPoE WAN interface that connects to the OR modem and I've also attached some PPPoE debug logs from the SonicWALL. Please let me know if you have any trouble receiving them.
This happens with a whole range of different SonicWALL models, from TZ100 / 200's to TZ105's and even the newest SOHO devices. Our LNS that these sessions are hosted on is a Firebrick FB6202 Running FB6202 Nestor+ (V1.35.019 2015-02-11T17:21:55) firmware. The logs off of that for this particular FTTC PPPoE session from this SonicWALL are as follows. We have checked and double-checked our RADIUS servers and the username / password combos are definitely correct, so there's no issue there. Thanks. 28 Jan 2017 19:24:22 l2tp-rx T13092-51756-62.24.203.227 S17150-9461 request lts001.hex NMCIHW eth 0/1/17:101@FTTC1264195 28 Jan 2017 19:24:22 l2tp-rx T13092-51756-62.24.203.227 S17150-9461 incoming NMCIHW eth 0/1/17:101@FTTC1264195 28 Jan 2017 19:24:22 l2tp-rx T13092-51756-62.24.203.227 S17150-9461 PPP Init Rx C021:LCP 01 01 000E ConfReq 01:MRU 04 1492 05:MAGIC 06 29:97:fe:3b [email protected] 28 Jan 2017 19:24:22 l2tp-rx T13092-51756-62.24.203.227 S17150-9461 PPP Last Rx C021:LCP 01 01 000E ConfReq 01:MRU 04 1492 05:MAGIC 06 29:97:fe:3b [email protected] 28 Jan 2017 19:24:22 l2tp-rx T13092-51756-62.24.203.227 S17150-9461 PPP Last Tx C021:LCP 01 01 000F ConfReq 03:AUTH 05 c2:23:05 05:MAGIC 06 0a:d4:9c:d4 [email protected] 28 Jan 2017 19:24:22 l2tp-rx T13092-51756-62.24.203.227 S17150-9461 PPP Auth name 6d:63:6d:66:6d:74:32:40:63:6f:6e:6e:65:63:74:2e:63:6c:65:61:72:73:74:72:65:61:6d:67:72:6f:75:70:2e:63:6f:2e:75:6b [[email protected]] 28 Jan 2017 19:24:22 l2tp-rx T13092-51756-62.24.203.227 S17150-9461 PPP Auth chal 15 57:7d:f2:7f:ea:06:6c:ff:f8:a8:3c:7d:f9:6f:59:a6 28 Jan 2017 19:24:22 l2tp-rx T13092-51756-62.24.203.227 S17150-9461 PPP Auth response 8c:8c:b0:d3:76:4e:b4:5c:de:60:76:80:83:9c:78:cf 28 Jan 2017 19:24:22 l2tp-rx T13092-51756-62.24.203.227 S17150-9461 connect [email protected] 39956000/9999000bps mtu1492 28 Jan 2017 19:24:22 radius-rx T13092-51756-62.24.203.227 S17150-9461 PPP Tx C223:CHAP 03 15 0004 [email protected] 28 Jan 2017 19:24:22 radius-rx T13092-51756-62.24.203.227 S17150-9461 PPP Tx C021:LCP 01 01 000E ConfReq 05:MAGIC 06 0a:d4:9c:d4 01:MRU 04 1472 [email protected] 28 Jan 2017 19:24:22 l2tp-rx T13092-51756-62.24.203.227 S17150-9461 PPP Rx FF03 8021:IPCP 01 01 0016 ConfReq 03:IP 06 0.0.0.0 81:DNS1 06 0.0.0.0 83:DNS2 06 0.0.0.0 [email protected] 28 Jan 2017 19:24:22 l2tp-rx T13092-51756-62.24.203.227 S17150-9461 PPP Tx 8021:IPCP 03 01 0016 ConfNak 03:IP 06 46.17.214.185 81:DNS1 06 185.23.52.131 83:DNS2 06 185.23.52.132 [email protected] 28 Jan 2017 19:24:22 l2tp-rx T13092-51756-62.24.203.227 S17150-9461 PPP Rx FF03 8057:IPV6CP 01 01 000E ConfReq 01:I/F 0A c2:ea:e4:ff:fe:7a:16:e6 [email protected] 28 Jan 2017 19:24:22 l2tp-rx T13092-51756-62.24.203.227 S17150-9461 PPP Tx C021:LCP 08 01 0014 ProtoRej 8057 01 01 000E ConfReq 01:I/F 0A c2:ea:e4:ff:fe:7a:16:e6 [email protected] 28 Jan 2017 19:24:22 l2tp-rx T13092-51756-62.24.203.227 S17150-9461 PPP Rx FF03 C021:LCP 01 02 000E ConfReq 01:MRU 04 1492 05:MAGIC 06 29:97:fe:3b [email protected] 28 Jan 2017 19:24:22 l2tp-rx T13092-51756-62.24.203.227 S17150-9461 PPP Tx C021:LCP 02 02 000E ConfAck 01:MRU 04 1492 05:MAGIC 06 29:97:fe:3b [email protected] 28 Jan 2017 19:24:22 l2tp-rx T13092-51756-62.24.203.227 S17150-9461 PPP Rx FF03 C021:LCP 02 01 000E ConfAck 05:MAGIC 06 0a:d4:9c:d4 01:MRU 04 1472 [email protected] 28 Jan 2017 19:24:22 l2tp-rx T13092-51756-62.24.203.227 S17150-9461 PPP Tx 8021:IPCP 01 00 000A ConfReq 03:IP 06 62.24.191.98 [email protected] 28 Jan 2017 19:24:22 l2tp-rx T10838-3606-62.24.203.91 S24816-43992 PPP Rx FF03 C021:LCP 08 B1 0040 ProtoRej AAAA 03 00 00 00 08 06 00 13 08 00 00 00 00 08 04 00 00 00 71 q 72 r 73 s 74 t FD 12 A5 AD BA 38 8 8E BD FB 55 U 50 P 18 10 00 F8 E0 00 00 17 03 03 00 50 P D6 07 80 20 81 D2 6F o 57 W B8 CC 9C 2E . 0F 28 Jan 2017 19:24:22 l2tp-rx T10838-3606-62.24.203.91 S43511-28544 PPP Rx FF03 C021:LCP 08 E9 001C ProtoRej AAAA 03 00 00 00 08 06 00 13 08 00 00 00 00 08 04 00 00 00 71 q 72 r 73 s 74 t Regards, Gareth. From: Neil J. McRae [mailto:[email protected]] Sent: 28 January 2017 15:57 To: Gareth Phillips <[email protected]> Cc: [email protected] Subject: Re: [uknof] SonicWALL PPPoE Issues over Talk-Talk WFTTC Circuits Suggest you do a wire shark between the OR modem and this box. It will show what's going on. Neil Sent from my iPhone On 28 Jan 2017, at 15:34, Gareth Phillips <[email protected]<mailto:[email protected]>> wrote: Hello all, We're an ISP re-selling Talk-Talk wholesale LLU DSL and Wholesale FTTC circuits to a UK national customer base. Within the last couple of weeks we've started noticing that our customers that are using a SonicWALL firewall / BT Openreach modem combination on FTTC circuits (authenticating over PPPoE) have started to disconnect and simply will not come back online again. This has only affected our customers using these SonicWALLs on FTTC so far - nobody else. These same devices worked flawlessly on the BT WBMC network for several years without any issues and have recently worked flawlessly on the Talk Talk network for roughly one year until now. Talk-Talk have been carrying out a series of software / network upgrades this month and we suspect that it's probably related to one of those. We've been in touch with Talk Talk Support and they are investigating the issue but they don't seem to be having much luck at this stage. I was hoping that somebody out there may have experienced / noticed the same thing. I realise that this issue is quite specific, so unless you're using this kit in this configuration with this provider, then you may have not. The only thing that seems to resolve this at the moment is a complete hardware replacement with a Billion router, which is what we use at a number of our other customer sites. The Openreach modem remains in place so we know it's not an issue with that. The connection then comes back up without issue. Things we have tried so far... * Changing the MTU on the SonicWALL WAN taking it right down from 1500 in increments to below 1300. * We've tried a RADIUS Filter-ID of "l" (lower case L) to stop MRU renegotiation and a similar hard coded setting on the L2TP LNS tunnel for those particular circuits. * We've tried configuring a fixed MTU on the L2TP LNS tunnel for those particular circuits. * We've tried disabling IPv6 on the SonicWALL WAN interface doing the PPPoE authentication / negotiation. * We've tried switching both the SonicWALL and modem off for over half an hour to kill any potential stale sessions. Thank you. Kind Regards, Gareth Phillips. Disclaimer: Views or opinions presented are solely those of the author and do not necessarily represent those of Clearstream Technology Ltd or Clearstream Technology Group Ltd (Clearstream). Confidentiality: This email and any attached files are confidential and intended solely for the use of the individual(s) to whom it is addressed. If you are not the intended recipient, you have received this email in error and any use, dissemination, forwarding, printing or copying of this email is strictly prohibited. If you have received this email in error please contact the sender. Security: This e-mail has been created in the knowledge that Internet e-mail is not a 100% secure communications medium. We advise that you understand and observe this lack of security when e-mailing us. Although this email and any attachments are believed to be free of any virus or other defects which might affect any computer or IT system into which they are received, no responsibility is accepted by Clearstream or any of its associated companies for any loss or damage arising in any way from the receipt or use thereof.
Customer_Packet-Capture.pcap
Description: Customer_Packet-Capture.pcap
Customer_SonicWALL_Logs.xlsx
Description: Customer_SonicWALL_Logs.xlsx
