Netgate Discussion Forum
    • Categories
    • Recent
    • Tags
    • Popular
    • Users
    • Search
    • Register
    • Login

    Gateway alarm: WAN_PPPOE

    Scheduled Pinned Locked Moved General pfSense Questions
    24 Posts 5 Posters 1.7k Views 5 Watching
    Loading More Posts
    • Oldest to Newest
    • Newest to Oldest
    • Most Votes
    Reply
    • Reply as topic
    Log in to reply
    This topic has been deleted. Only users with topic management privileges can see it.
    • W Offline
      wheelhouse20 @viragomann
      last edited by wheelhouse20

      @viragomann ztlink mt992 modem dont give out info. my connection is Gfast.

      https://www.thinkbroadband.com/broadband/monitoring/quality/share/4b2c345cf4383d79b99aff29793e2c9eb3e44a8c-27-02-2022
      https://www.thinkbroadband.com/broadband/monitoring/quality/share/cf6757946802c9bcb9d362083565b5642d5c2fd6

      1 Reply Last reply Reply Quote 0
      • stephenw10S Offline
        stephenw10 Netgate Administrator @wheelhouse20
        last edited by

        @wheelhouse20 said in Gateway alarm: WAN_PPPOE:

        Feb 28 14:25:53 dpinger 51689 send_interval 500ms loss_interval 2000ms time_period 60000ms report_interval 0ms data_len 1 alert_interval 1000ms latency_alarm 500ms loss_alarm 20% dest_addr 10.12.12.14 bind_addr 12.34.56.78 identifier "WAN_PPPOE "

        That's not a gateway alarm. That's a log from dpinger starting showing it's config on that interface.

        An alarm looks like:

        Feb 28 07:16:44	rc.gateway_alarm	19336	>>> Gateway alarm: WAN_PPPOE (Addr:10.12.12.14 Alarm:1 RTT:19.163ms RTTsd:.325ms Loss:21%)
        

        Shown there because the packet loss went over the 20% threshold set when it started.

        And there it's because the PPPoE failed:

        Feb 28 07:17:32	ppp	9483	[wan_link0] LCP: state change Opened --> Stopping
        Feb 28 07:17:32	ppp	9483	[wan_link0] LCP: peer not responding to echo requests
        Feb 28 07:17:32	ppp	9483	[wan_link0] LCP: no reply to 5 echo request(s)
        Feb 28 07:17:22	ppp	9483	[wan_link0] LCP: no reply to 4 echo request(s)
        Feb 28 07:17:11	ppp	9483	[wan_link0] LCP: no reply to 3 echo request(s)
        Feb 28 07:17:01	ppp	9483	[wan_link0] LCP: no reply to 2 echo request(s)
        Feb 28 07:16:51	ppp	9483	[wan_link0] LCP: no reply to 1 echo request(s)
        

        Nothing pfSense can do if it fails at the LCP layer. So it kills tje old connections and starts trying to reconnect. And about 30s later it does:

        Feb 28 07:18:01	ppp	9483	[wan] IFACE: Add description "WAN"
        Feb 28 07:18:01	ppp	9483	[wan] IFACE: Rename interface ng0 to pppoe0
        Feb 28 07:18:01	ppp	9483	[wan] IFACE: Up event
        Feb 28 07:18:01	check_reload_status	409	rc.newwanip starting pppoe0
        Feb 28 07:18:01	ppp	9483	[wan] 12.34.56.78 -> 10.12.12.14
        Feb 28 07:18:01	ppp	9483	[wan] IPCP: LayerUp
        Feb 28 07:18:01	ppp	9483	[wan] IPCP: state change Ack-Sent --> Opened
        Feb 28 07:18:01	ppp	9483	[wan] IPADDR 12.34.56.78
        

        Then later it fails for the same reason. Probably a bad line card or something upstream.
        I would suggest trying a different modem but those are like gold dust. I know!

        I would change the gateway monitoring IP to something upstream of the gateway, like 8.8.8.8. That will give you a far better idea of the actual connection quality.
        What sort of connection speeds do you see? Are you toward the maximum distance for g.fast?

        Steve

        W V 2 Replies Last reply Reply Quote 0
        • W Offline
          wheelhouse20 @stephenw10
          last edited by stephenw10

          @stephenw10
          The internet was fine for a about 4-5 days then pfblocker updated then the gateway alarm came at the end. Im about 110 meters from the cabinet and my max speed are 310-down 48-up, i pay for 330-down 48-up. the modem was installed by bt-openreachand id rather not pay for a replacement right now.
          i have changed from 1.1.1.3 to 8.8.8.8.

          Feb 28 07:17:32	ppp	9483	[wan_link0] LCP: peer not responding to echo requests
          Feb 28 07:17:32	ppp	9483	[wan_link0] LCP: no reply to 5 echo request(s)
          Feb 28 07:17:22	ppp	9483	[wan_link0] LCP: no reply to 4 echo request(s)
          Feb 28 07:17:11	ppp	9483	[wan_link0] LCP: no reply to 3 echo request(s)
          Feb 28 07:17:01	ppp	9483	[wan_link0] LCP: no reply to 2 echo request(s)
          Feb 28 07:16:51	ppp	9483	[wan_link0] LCP: no reply to 1 echo request(s)
          Feb 28 07:16:45	php-fpm	370	/rc.openvpn: Gateway, none 'available' for inet6, use the first one configured. ''
          Feb 28 07:16:45	php-fpm	370	/rc.openvpn: Gateway, none 'available' for inet, use the first one configured. 'WAN_PPPOE'
          Feb 28 07:16:44	check_reload_status	409	Reloading filter
          Feb 28 07:16:44	check_reload_status	409	Restarting OpenVPN tunnels/interfaces
          Feb 28 07:16:44	check_reload_status	409	Restarting IPsec tunnels
          Feb 28 07:16:44	check_reload_status	409	updating dyndns WAN_PPPOE
          Feb 28 07:16:44	rc.gateway_alarm	19336	>>> Gateway alarm: WAN_PPPOE (Addr:10.12.12.14 Alarm:1 RTT:19.163ms RTTsd:.325ms Loss:21%)
          Feb 28 07:02:00	sshguard	69726	Now monitoring attacks.
          Feb 28 07:02:00	sshguard	49987	Exiting on signal.
          Feb 28 07:00:00	php	96239	[pfBlockerNG] No changes to Firewall rules, skipping Filter Reload
          Feb 28 07:00:00	php	96239	[pfBlockerNG] Starting cron process.
          Feb 28 06:00:00	php	50130	[pfBlockerNG] No changes to Firewall rules, skipping Filter Reload
          Feb 28 06:00:00	php	50130	[pfBlockerNG] Starting cron process.
          Feb 28 05:00:00	php	75827	[pfBlockerNG] No changes to Firewall rules, skipping Filter Reload
          Feb 28 05:00:00	php	75827	[pfBlockerNG] Starting cron process.
          Feb 28 04:00:00	php	7032	[pfBlockerNG] No changes to Firewall rules, skipping Filter Reload
          Feb 28 04:00:00	php	7032	[pfBlockerNG] Starting cron process.
          Feb 28 03:00:00	php	29155	[pfBlockerNG] No changes to Firewall rules, skipping Filter Reload
          Feb 28 03:00:00	php	29155	[pfBlockerNG] Starting cron process.
          Feb 28 02:00:00	php	57649	[pfBlockerNG] No changes to Firewall rules, skipping Filter Reload
          Feb 28 02:00:00	php	57649	[pfBlockerNG] Starting cron process.
          Feb 28 01:06:00	sshguard	49987	Now monitoring attacks.
          Feb 28 01:06:00	sshguard	8869	Exiting on signal.
          Feb 28 01:00:00	php	82674	[pfBlockerNG] No changes to Firewall rules, skipping Filter Reload
          Feb 28 01:00:00	php	82674	[pfBlockerNG] Starting cron process.
          Feb 28 00:00:36	php	68430	[pfBlockerNG] No changes to Firewall rules, skipping Filter Reload
          Feb 28 00:00:00	php	68430	[pfBlockerNG] Starting cron process.
          Feb 27 23:00:00	php	92181	[pfBlockerNG] No changes to Firewall rules, skipping Filter Reload
          Feb 27 23:00:00	php	92181	[pfBlockerNG] Starting cron process.
          Feb 27 22:00:00	php	23443	[pfBlockerNG] No changes to Firewall rules, skipping Filter Reload
          Feb 27 22:00:00	php	23443	[pfBlockerNG] Starting cron process.
          Feb 27 21:00:00	php	9357	[pfBlockerNG] No changes to Firewall rules, skipping Filter Reload
          Feb 27 21:00:00	php	9357	[pfBlockerNG] Starting cron process.
          Feb 27 20:02:00	sshguard	8869	Now monitoring attacks.
          Feb 27 20:02:00	sshguard	99989	Exiting on signal.
          Feb 27 20:00:00	php	37363	[pfBlockerNG] No changes to Firewall rules, skipping Filter Reload
          Feb 27 20:00:00	php	37363	[pfBlockerNG] Starting cron process.
          
          fireodoF 1 Reply Last reply Reply Quote 0
          • fireodoF Offline
            fireodo @wheelhouse20
            last edited by fireodo

            @wheelhouse20 said in Gateway alarm: WAN_PPPOE:

            Feb 28 07:17:32 ppp 9483 [wan_link0] LCP: peer not responding to echo requests
            Feb 28 07:17:32 ppp 9483 [wan_link0] LCP: no reply to 5 echo request(s)
            Feb 28 07:17:22 ppp 9483 [wan_link0] LCP: no reply to 4 echo request(s)

            Hi, this indicates a Provider Problem and not a Gateway issue ... IMHO (could be a Modem Problem too)

            regards,
            fireodo

            Kettop Mi4300YL CPU: i5-4300Y @ 1.60GHz RAM: 8GB Ethernet Ports: 4
            SSD: SanDisk pSSD-S2 16GB (ZFS) WiFi: WLE200NX
            pfsense 2.8.0 CE
            Packages: Apcupsd, Cron, Iftop, Iperf, LCDproc, Nmap, pfBlockerNG, RRD_Summary, Shellcmd, Snort, Speedtest, System_Patches.

            W 1 Reply Last reply Reply Quote 0
            • W Offline
              wheelhouse20 @fireodo
              last edited by stephenw10

              @fireodo
              This dosent indicate any thing as it take time to reconnect after losing the connection.
              also im looking for why the connect lost if the fist place ie pfblocker/rc.update_urltables.

              Feb 28 12:38:42	ppp	9483	[wan] Bundle: Status update: up 0 links, total bandwidth 9600 bps
              Feb 28 12:38:42	ppp	9483	[wan_link0] Link: Leave bundle "wan"
              Feb 28 12:38:42	ppp	9483	[wan_link0] LCP: state change Opened --> Stopping
              Feb 28 12:38:42	ppp	9483	[wan_link0] LCP: peer not responding to echo requests
              Feb 28 12:38:42	ppp	9483	[wan_link0] LCP: no reply to 5 echo request(s)
              Feb 28 12:38:32	ppp	9483	[wan_link0] LCP: no reply to 4 echo request(s)
              Feb 28 12:38:22	ppp	9483	[wan_link0] LCP: no reply to 3 echo request(s)
              Feb 28 12:38:12	ppp	9483	[wan_link0] LCP: no reply to 2 echo request(s)
              Feb 28 12:38:02	ppp	9483	[wan_link0] LCP: no reply to 1 echo request(s)
              Feb 28 12:37:55	php-fpm	370	/rc.openvpn: Gateway, none 'available' for inet6, use the first one configured. ''
              Feb 28 12:37:55	php-fpm	370	/rc.openvpn: Gateway, none 'available' for inet, use the first one configured. 'WAN_PPPOE'
              Feb 28 12:37:54	check_reload_status	409	Reloading filter
              Feb 28 12:37:54	check_reload_status	409	Restarting OpenVPN tunnels/interfaces
              Feb 28 12:37:54	check_reload_status	409	Restarting IPsec tunnels
              Feb 28 12:37:54	check_reload_status	409	updating dyndns WAN_PPPOE
              Feb 28 12:37:54	rc.gateway_alarm	13430	>>> Gateway alarm: WAN_PPPOE (Addr:10.12.12.14 Alarm:1 RTT:18.385ms RTTsd:.317ms Loss:22%)
              Feb 28 12:30:59	php	56119	rc.update_urltables: /etc/rc.update_urltables: pfB_PRI3_v4 does not need updating.
              Feb 28 12:30:59	php	56119	rc.update_urltables: /etc/rc.update_urltables: pfB_PRI4_v4 does not need updating.
              Feb 28 12:30:59	php	56119	rc.update_urltables: /etc/rc.update_urltables: pfB_PRI5_v4 does not need updating.
              Feb 28 12:30:59	php	56119	rc.update_urltables: /etc/rc.update_urltables: pfB_PRI1_v4 does not need updating.
              Feb 28 12:30:59	php	56119	rc.update_urltables: /etc/rc.update_urltables: pfB_Europe_v6 does not need updating.
              Feb 28 12:30:59	php	56119	rc.update_urltables: /etc/rc.update_urltables: pfB_Europe_v4 does not need updating.
              Feb 28 12:30:59	php	56119	rc.update_urltables: /etc/rc.update_urltables: Starting URL table alias updates
              Feb 28 12:30:00	php	56119	rc.update_urltables: /etc/rc.update_urltables: Sleeping for 59 seconds.
              Feb 28 12:30:00	php	56119	rc.update_urltables: /etc/rc.update_urltables: Starting up.
              Feb 28 12:00:00	php	54612	[pfBlockerNG] No changes to Firewall rules, skipping Filter Reload
              Feb 28 12:00:00	php	54612	[pfBlockerNG] Starting cron process.
              Feb 28 11:00:00	php	72144	[pfBlockerNG] No changes to Firewall rules, skipping Filter Reload
              Feb 28 11:00:00	php	72144	[pfBlockerNG] Starting cron process.
              Feb 28 10:00:00	php	10495	[pfBlockerNG] No changes to Firewall rules, skipping Filter Reload
              Feb 28 10:00:00	php	10495	[pfBlockerNG] Starting cron process.
              Feb 28 09:00:00	php	38311	[pfBlockerNG] No changes to Firewall rules, skipping Filter Reload
              Feb 28 09:00:00	php	38311	[pfBlockerNG] Starting cron process.
              Feb 28 08:00:00	php	13474	[pfBlockerNG] No changes to Firewall rules, skipping Filter Reload
              Feb 28 08:00:00	php	13474	[pfBlockerNG] Starting cron process.
              
              Feb 28 07:17:32	ppp	9483	[wan_link0] Link: Leave bundle "wan"
              Feb 28 07:17:32	ppp	9483	[wan_link0] LCP: state change Opened --> Stopping
              Feb 28 07:17:32	ppp	9483	[wan_link0] LCP: peer not responding to echo requests
              Feb 28 07:17:32	ppp	9483	[wan_link0] LCP: no reply to 5 echo request(s)
              Feb 28 07:17:22	ppp	9483	[wan_link0] LCP: no reply to 4 echo request(s)
              Feb 28 07:17:11	ppp	9483	[wan_link0] LCP: no reply to 3 echo request(s)
              Feb 28 07:17:01	ppp	9483	[wan_link0] LCP: no reply to 2 echo request(s)
              Feb 28 07:16:51	ppp	9483	[wan_link0] LCP: no reply to 1 echo request(s)
              Feb 28 07:16:45	php-fpm	370	/rc.openvpn: Gateway, none 'available' for inet6, use the first one configured. ''
              Feb 28 07:16:45	php-fpm	370	/rc.openvpn: Gateway, none 'available' for inet, use the first one configured. 'WAN_PPPOE'
              Feb 28 07:16:44	check_reload_status	409	Reloading filter
              Feb 28 07:16:44	check_reload_status	409	Restarting OpenVPN tunnels/interfaces
              Feb 28 07:16:44	check_reload_status	409	Restarting IPsec tunnels
              Feb 28 07:16:44	check_reload_status	409	updating dyndns WAN_PPPOE
              Feb 28 07:16:44	rc.gateway_alarm	19336	>>> Gateway alarm: WAN_PPPOE (Addr:10.12.12.14 Alarm:1 RTT:19.163ms RTTsd:.325ms Loss:21%)
              Feb 28 07:02:00	sshguard	69726	Now monitoring attacks.
              Feb 28 07:02:00	sshguard	49987	Exiting on signal.
              Feb 28 07:00:00	php	96239	[pfBlockerNG] No changes to Firewall rules, skipping Filter Reload
              Feb 28 07:00:00	php	96239	[pfBlockerNG] Starting cron process.
              Feb 28 06:00:00	php	50130	[pfBlockerNG] No changes to Firewall rules, skipping Filter Reload
              Feb 28 06:00:00	php	50130	[pfBlockerNG] Starting cron process.
              Feb 28 05:00:00	php	75827	[pfBlockerNG] No changes to Firewall rules, skipping Filter Reload
              Feb 28 05:00:00	php	75827	[pfBlockerNG] Starting cron process.
              Feb 28 04:00:00	php	7032	[pfBlockerNG] No changes to Firewall rules, skipping Filter Reload
              Feb 28 04:00:00	php	7032	[pfBlockerNG] Starting cron process.
              Feb 28 03:00:00	php	29155	[pfBlockerNG] No changes to Firewall rules, skipping Filter Reload
              Feb 28 03:00:00	php	29155	[pfBlockerNG] Starting cron process.
              Feb 28 02:00:00	php	57649	[pfBlockerNG] No changes to Firewall rules, skipping Filter Reload
              Feb 28 02:00:00	php	57649	[pfBlockerNG] Starting cron process.
              
              1 Reply Last reply Reply Quote 0
              • V Offline
                viragomann @stephenw10
                last edited by

                @stephenw10 said in Gateway alarm: WAN_PPPOE:

                I would suggest trying a different modem but those are like gold dust. I know!

                That seems to hit the bull's eye here.

                @wheelhouse20 said in Gateway alarm: WAN_PPPOE:

                also im looking for why the connect lost if the fist place ie pfblocker/rc.update_urltables.

                I cannot see any relation with pfBlockerNG in the logs.

                1 Reply Last reply Reply Quote 0
                • stephenw10S Offline
                  stephenw10 Netgate Administrator
                  last edited by

                  @wheelhouse20 said in Gateway alarm: WAN_PPPOE:

                  modem was installed by bt-openreach

                  Lucky, they'd stopped giving those out by the time I got g.fast.

                  Yeah, this is nothing to do with pfBlocker updates.

                  The remote side of the DSL stops responding to LCP 15mins after the update.
                  There's nothing pfSense can do about that except kill the ppp session and start over.

                  Steve

                  1 Reply Last reply Reply Quote 1
                  • NollipfSenseN Offline
                    NollipfSense @wheelhouse20
                    last edited by

                    @wheelhouse20 You're experiencing the same dpinger issue...I get those alarms as well. Here is snapshot last time mine happened:

                    Clear latency 8561us stddev 5618us loss 15%
                    Feb 23 09:04:51 dpinger 55934 WAN_DHCP xx.xxx.xxx.1: Alarm latency 11829us stddev 8213us loss 21%
                    Feb 23 09:05:17 dpinger 55934 WAN_DHCP xx.xxx.xxx.1: Clear latency 11452us stddev 8133us loss 20%
                    Feb 23 09:05:31 dpinger 55934 WAN_DHCP xx.xxx.xxx.1: Alarm latency 10222us stddev 6298us loss 21%
                    Feb 23 09:05:48 dpinger 55934 WAN_DHCP xx.xxx.xxx.1: Clear latency 8644us stddev 5458us loss 14%
                    Feb 23 10:04:10 dpinger 55934 WAN_DHCP xx.xxx.xxx.1: Alarm latency 9920us stddev 6204us loss 21%
                    Feb 23 10:05:20 dpinger 55934 WAN_DHCP xx.xxx.xxx.1: Clear latency 8879us stddev 4871us loss 20%

                    pfSense+ 23.09 Lenovo Thinkcentre M93P SFF Quadcore i7 dual Raid-ZFS 128GB-SSD 32GB-RAM PCI-Intel i350-t4 NIC, -Intel QAT 8950.
                    pfSense+ 23.09 VM-Proxmox, Dell Precision Xeon-W2155 Nvme 500GB-ZFS 128GB-RAM PCIe-Intel i350-t4, Intel QAT-8950, P-cloud.

                    W 1 Reply Last reply Reply Quote 0
                    • stephenw10S Offline
                      stephenw10 Netgate Administrator
                      last edited by

                      That's a different cause though since you're using DHCP and this is a failure at the LCP level.

                      NollipfSenseN 1 Reply Last reply Reply Quote 1
                      • W Offline
                        wheelhouse20 @NollipfSense
                        last edited by

                        @nollipfsense

                        Dpinger
                        Dpinger.txt

                        1 Reply Last reply Reply Quote 0
                        • W Offline
                          wheelhouse20
                          last edited by

                          This post is deleted!
                          1 Reply Last reply Reply Quote 0
                          • NollipfSenseN Offline
                            NollipfSense @stephenw10
                            last edited by

                            @stephenw10 said in Gateway alarm: WAN_PPPOE:

                            That's a different cause though since you're using DHCP and this is a failure at the LCP level.

                            Okay.

                            pfSense+ 23.09 Lenovo Thinkcentre M93P SFF Quadcore i7 dual Raid-ZFS 128GB-SSD 32GB-RAM PCI-Intel i350-t4 NIC, -Intel QAT 8950.
                            pfSense+ 23.09 VM-Proxmox, Dell Precision Xeon-W2155 Nvme 500GB-ZFS 128GB-RAM PCIe-Intel i350-t4, Intel QAT-8950, P-cloud.

                            1 Reply Last reply Reply Quote 0
                            • W Offline
                              wheelhouse20
                              last edited by

                              my WAN has been UP for 4 days then get an rc.gateway_alarm again must be something todo with with dpinger.

                              Mar 9 20:29:02 rc.gateway_alarm 70547 >>> Gateway alarm: WAN_PPPOE (Addr:15.14.12.10 Alarm:1 RTT:7.122ms RTTsd:.307ms Loss:21%)

                              stephenw10S 1 Reply Last reply Reply Quote 0
                              • stephenw10S Offline
                                stephenw10 Netgate Administrator @wheelhouse20
                                last edited by

                                @wheelhouse20 said in Gateway alarm: WAN_PPPOE:

                                Loss:21%

                                Yup, the default packet loss alarm threshold is 20% so it should throw an alarm when it hits 21%. We can see from previous logs that you have not changed it from that default so that's correct.

                                I would expect to probably see the same LCP echo timeouts in the ppp log?

                                I note the mt992 g.fast modem seems to have got a lot cheaper since I bought one. I think I paid well north of £100 at the time. 😬 So if you are seeing LCP issues you might consider swapping it out but it's probably an upsteam issue. Either way there nothing pfSense can do there except restart the connection process.

                                Steve

                                W 1 Reply Last reply Reply Quote 0
                                • W Offline
                                  wheelhouse20 @stephenw10
                                  last edited by

                                  @stephenw10 what was i ment to change ?

                                  1 Reply Last reply Reply Quote 0
                                  • stephenw10S Offline
                                    stephenw10 Netgate Administrator
                                    last edited by

                                    I was suggesting you might change the modem if you can find one cheap enough. There have been some MT992s sold on ebay for <£20 recently. However I still think this is an upstream issue and that probably won't help.

                                    Steve

                                    W 1 Reply Last reply Reply Quote 1
                                    • W Offline
                                      wheelhouse20 @stephenw10
                                      last edited by

                                      @stephenw10 would my isp be able to fix the issue ?

                                      1 Reply Last reply Reply Quote 0
                                      • stephenw10S Offline
                                        stephenw10 Netgate Administrator
                                        last edited by

                                        Yes, they should be able to. Do you see the modem lose link when the LCP errors happen?
                                        Might be difficult to log that with no modem access.
                                        The ISP should be able to see the PPP connection failing. They can probably also see line stats including DSL link failures if they actually look.

                                        Steve

                                        W 1 Reply Last reply Reply Quote 0
                                        • W Offline
                                          wheelhouse20 @stephenw10
                                          last edited by

                                          @stephenw10 My isp has said they havent seen any erros on the line and keep refering me to use there fritz box,i also have a broadband quality monitor with thinkbroadband which only shows drops when i have reboot the system.

                                          do you think you could spare 5-10 mins to have a look at my set-up ? via discord or teamviewer

                                          1 Reply Last reply Reply Quote 0
                                          • stephenw10S Offline
                                            stephenw10 Netgate Administrator
                                            last edited by

                                            Are you still seeing the LCP timeouts in the PPP log when it fails?

                                            Where did you get the MT992 modem from? Perhaps it's bad?
                                            Try setting up a PPPoE sesion from something else using it and see if you still get disconnected.

                                            Try putting the Fritzbox back and see if that has disconnects at all.

                                            I can't do live support here, we have paid support for that. But in this case they would tell you the same thing: LCP timeouts like that are the other end failing to respond. pfSense can do nothing about that.

                                            Steve

                                            1 Reply Last reply Reply Quote 0
                                            • First post
                                              Last post
                                            Copyright 2025 Rubicon Communications LLC (Netgate). All rights reserved.