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

    lose the WAN connection

    Scheduled Pinned Locked Moved General pfSense Questions
    6 Posts 2 Posters 691 Views 2 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.
    • L Offline
      LMM
      last edited by

      Dear all,
      Every so often I lose the WAN connection.
      Can you please help me?

      Best regards,
      Miguel

      Here’s some information:
      #Gateways log
      Jul 31 09:37:53 dpinger WAN_DHCP 8.8.8.8: Clear latency 17426us stddev 293us loss 14%
      Jul 31 09:40:55 dpinger WAN_DHCP 8.8.8.8: Alarm latency 17541us stddev 189us loss 21%
      Jul 31 09:45:19 dpinger send_interval 500ms loss_interval 2000ms time_period 60000ms report_interval 0ms data_len 1 alert_interval 1000ms latency_alarm
      Jul 31 09:45:21 dpinger WAN_DHCP 8.8.8.8: Alarm latency 0us stddev 0us loss 100%

      #My system
      Pfsense 2.4.5-RELEASE-p1 (amd64)
      AMD Athlon(tm) 7750 Dual-Core Processor
      fiber WAN 1000baseT <full-duplex
      Memory, CPU and disk usage is ok
      ISP modem/router in bridge mode

      #Packet capture
      10:16:17.469909 IP 109.51.46.194 > 8.8.8.8: ICMP echo request, id 29005, seq 3145, length 9
      10:16:17.487456 IP 8.8.8.8 > 109.51.46.194: ICMP echo reply, id 29005, seq 3145, length 9
      10:16:17.995388 IP 109.51.46.194 > 8.8.8.8: ICMP echo request, id 29005, seq 3146, length 9
      10:16:18.013037 IP 8.8.8.8 > 109.51.46.194: ICMP echo reply, id 29005, seq 3146, length 9
      10:16:18.497254 IP 109.51.46.194 > 8.8.8.8: ICMP echo request, id 29005, seq 3147, length 9
      10:16:18.514627 IP 8.8.8.8 > 109.51.46.194: ICMP echo reply, id 29005, seq 3147, length 9
      10:16:19.009140 IP 109.51.46.194 > 8.8.8.8: ICMP echo request, id 29005, seq 3148, length 9
      10:16:19.026589 IP 8.8.8.8 > 109.51.46.194: ICMP echo reply, id 29005, seq 3148, length 9
      10:16:19.539134 IP 109.51.46.194 > 8.8.8.8: ICMP echo request, id 29005, seq 3149, length 9
      10:16:19.556667 IP 8.8.8.8 > 109.51.46.194: ICMP echo reply, id 29005, seq 3149, length 9
      10:16:20.071394 IP 109.51.46.194 > 8.8.8.8: ICMP echo request, id 29005, seq 3150, length 9
      10:16:20.088743 IP 8.8.8.8 > 109.51.46.194: ICMP echo reply, id 29005, seq 3150, length 9
      10:16:20.599140 IP 109.51.46.194 > 8.8.8.8: ICMP echo request, id 29005, seq 3151, length 9
      10:16:20.616822 IP 8.8.8.8 > 109.51.46.194: ICMP echo reply, id 29005, seq 3151, length 9
      10:16:21.058432 IP 109.51.46.194.26946 > 162.208.119.38.53: UDP, length 49
      10:16:21.060892 IP 109.51.46.194.47651 > 172.217.16.238.443: tcp 78
      10:16:21.060899 IP 109.51.46.194.47651 > 172.217.16.238.443: tcp 39
      10:16:21.060905 IP 109.51.46.194.47651 > 172.217.16.238.443: tcp 92
      10:16:21.077313 IP 172.217.16.238.443 > 109.51.46.194.47651: tcp 0
      10:16:21.077331 IP 172.217.16.238.443 > 109.51.46.194.47651: tcp 0
      10:16:21.077437 IP 172.217.16.238.443 > 109.51.46.194.47651: tcp 0
      10:16:21.077812 IP 172.217.16.238.443 > 109.51.46.194.47651: tcp 39
      10:16:21.103174 IP 172.217.16.238.443 > 109.51.46.194.47651: tcp 66
      10:16:21.103181 IP 172.217.16.238.443 > 109.51.46.194.47651: tcp 118
      10:16:21.103297 IP 172.217.16.238.443 > 109.51.46.194.47651: tcp 31
      10:16:21.103303 IP 172.217.16.238.443 > 109.51.46.194.47651: tcp 39
      10:16:21.103611 IP 109.51.46.194.47651 > 172.217.16.238.443: tcp 0
      10:16:21.103617 IP 109.51.46.194.47651 > 172.217.16.238.443: tcp 0
      10:16:21.104865 IP 109.51.46.194.47651 > 172.217.16.238.443: tcp 39
      10:16:21.126288 IP 172.217.16.238.443 > 109.51.46.194.47651: tcp 0
      10:16:21.126309 IP 109.51.46.194 > 8.8.8.8: ICMP echo request, id 29005, seq 3152, length 9
      10:16:21.143899 IP 8.8.8.8 > 109.51.46.194: ICMP echo reply, id 29005, seq 3152, length 9
      10:16:21.173512 IP 162.208.119.38.53 > 109.51.46.194.26946: UDP, length 105
      10:16:21.173640 IP 109.51.46.194.48542 > 208.123.73.80.53: UDP, length 44
      10:16:21.214104 IP 109.51.46.194.23339 > 162.208.119.38.53: UDP, length 44
      10:16:21.322800 IP 208.123.73.80.53 > 109.51.46.194.48542: UDP, length 101
      10:16:21.322867 IP 109.51.46.194.5942 > 162.208.119.38.53: UDP, length 50
      10:16:21.327798 IP 162.208.119.38.53 > 109.51.46.194.23339: UDP, length 101
      10:16:21.327874 IP 109.51.46.194.49450 > 162.208.119.38.53: UDP, length 50
      10:16:21.437989 IP 162.208.119.38.53 > 109.51.46.194.5942: UDP, length 82
      10:16:21.439561 IP 109.51.46.194.42355 > 162.208.119.41.443: tcp 0
      10:16:21.440180 IP 109.51.46.194.63611 > 162.208.119.41.443: tcp 0
      10:16:21.440984 IP 162.208.119.38.53 > 109.51.46.194.49450: UDP, length 82
      10:16:21.441042 IP 109.51.46.194.39754 > 162.208.119.38.53: UDP, length 50
      10:16:21.551172 IP 162.208.119.41.443 > 109.51.46.194.42355: tcp 0
      10:16:21.551612 IP 109.51.46.194.42355 > 162.208.119.41.443: tcp 0
      10:16:21.551985 IP 109.51.46.194.42355 > 162.208.119.41.443: tcp 517
      10:16:21.554170 IP 162.208.119.41.443 > 109.51.46.194.63611: tcp 0
      10:16:21.554483 IP 109.51.46.194.63611 > 162.208.119.41.443: tcp 0
      10:16:21.554983 IP 109.51.46.194.63611 > 162.208.119.41.443: tcp 517
      10:16:21.555669 IP 162.208.119.38.53 > 109.51.46.194.39754: UDP, length 82
      10:16:21.658578 IP 109.51.46.194 > 8.8.8.8: ICMP echo request, id 29005, seq 3153, length 9
      10:16:21.666485 IP 162.208.119.41.443 > 109.51.46.194.42355: tcp 1460
      10:16:21.666607 IP 162.208.119.41.443 > 109.51.46.194.42355: tcp 1460
      10:16:21.666614 IP 162.208.119.41.443 > 109.51.46.194.42355: tcp 1345
      10:16:21.667296 IP 109.51.46.194.42355 > 162.208.119.41.443: tcp 0
      10:16:21.670668 IP 109.51.46.194.42355 > 162.208.119.41.443: tcp 126
      10:16:21.671168 IP 109.51.46.194.42355 > 162.208.119.41.443: tcp 681
      10:16:21.672479 IP 162.208.119.41.443 > 109.51.46.194.63611: tcp 1460
      10:16:21.672603 IP 162.208.119.41.443 > 109.51.46.194.63611: tcp 1460
      10:16:21.672610 IP 162.208.119.41.443 > 109.51.46.194.63611: tcp 1345
      10:16:21.673292 IP 109.51.46.194.63611 > 162.208.119.41.443: tcp 0
      10:16:21.675036 IP 109.51.46.194.63611 > 162.208.119.41.443: tcp 126
      10:16:21.675977 IP 8.8.8.8 > 109.51.46.194: ICMP echo reply, id 29005, seq 3153, length 9
      10:16:21.782043 IP 162.208.119.41.443 > 109.51.46.194.42355: tcp 51
      10:16:21.783168 IP 162.208.119.41.443 > 109.51.46.194.42355: tcp 515
      10:16:21.783981 IP 109.51.46.194.42355 > 162.208.119.41.443: tcp 0
      10:16:21.788602 IP 109.51.46.194.47651 > 172.217.16.238.443: tcp 78
      10:16:21.788608 IP 109.51.46.194.47651 > 172.217.16.238.443: tcp 93
      10:16:21.789663 IP 162.208.119.41.443 > 109.51.46.194.63611: tcp 51
      10:16:21.789726 IP 109.51.46.194.42355 > 162.208.119.41.443: tcp 682
      10:16:21.805032 IP 172.217.16.238.443 > 109.51.46.194.47651: tcp 0
      10:16:21.805154 IP 172.217.16.238.443 > 109.51.46.194.47651: tcp 0
      10:16:21.830141 IP 172.217.16.238.443 > 109.51.46.194.47651: tcp 66
      10:16:21.830148 IP 172.217.16.238.443 > 109.51.46.194.47651: tcp 120
      10:16:21.830265 IP 172.217.16.238.443 > 109.51.46.194.47651: tcp 31
      10:16:21.830390 IP 172.217.16.238.443 > 109.51.46.194.47651: tcp 39
      10:16:21.830453 IP 109.51.46.194.63611 > 162.208.119.41.443: tcp 0
      10:16:21.830577 IP 109.51.46.194.47651 > 172.217.16.238.443: tcp 0
      10:16:21.830701 IP 109.51.46.194.47651 > 172.217.16.238.443: tcp 0
      10:16:21.831946 IP 109.51.46.194.47651 > 172.217.16.238.443: tcp 39
      10:16:21.853251 IP 172.217.16.238.443 > 109.51.46.194.47651: tcp 0
      10:16:21.904727 IP 162.208.119.41.443 > 109.51.46.194.42355: tcp 1460
      10:16:21.904737 IP 162.208.119.41.443 > 109.51.46.194.42355: tcp 1460
      10:16:21.904743 IP 162.208.119.41.443 > 109.51.46.194.42355: tcp 188
      10:16:21.905905 IP 109.51.46.194.42355 > 162.208.119.41.443: tcp 0
      10:16:21.947391 IP 109.51.46.194.42355 > 162.208.119.41.443: tcp 0
      10:16:22.143154 IP 109.51.46.194.42355 > 162.208.119.41.443: tcp 552
      10:16:22.143388 IP 109.51.46.194.123 > 195.22.17.7.123: UDP, length 48
      10:16:22.153584 IP 195.22.17.7.123 > 109.51.46.194.123: UDP, length 48
      10:16:22.190830 IP 109.51.46.194 > 8.8.8.8: ICMP echo request, id 29005, seq 3154, length 9
      10:16:22.208555 IP 8.8.8.8 > 109.51.46.194: ICMP echo reply, id 29005, seq 3154, length 9
      10:16:22.254776 IP 162.208.119.41.443 > 109.51.46.194.42355: tcp 1460
      10:16:22.254785 IP 162.208.119.41.443 > 109.51.46.194.42355: tcp 320
      10:16:22.256092 IP 109.51.46.194.42355 > 162.208.119.41.443: tcp 0
      10:16:22.327804 IP 109.51.46.194.10328 > 13.225.247.219.443: tcp 71
      10:16:22.327811 IP 109.51.46.194.10328 > 13.225.247.219.443: tcp 46
      10:16:22.337355 IP 13.225.247.219.443 > 109.51.46.194.10328: tcp 0
      10:16:22.337480 IP 13.225.247.219.443 > 109.51.46.194.10328: tcp 0
      10:16:22.337730 IP 13.225.247.219.443 > 109.51.46.194.10328: tcp 46

      GertjanG 1 Reply Last reply Reply Quote 0
      • GertjanG Offline
        Gertjan @LMM
        last edited by

        @LMM said in lose the WAN connection:

        Can you please help me?

        Yeah.
        You are aware what the process 'dpinger' does ? What happens when the IP, where it sends ICMP packets to, isn't answering any more ? dpinger deducts that the connection is bad, and pulls the plug = resetting the WAN interface.

        You already know what "8.8.8.8" is, and guess what : replying to ping isn't it's main purpose. When "8.8.8.8" gets overworked, it will start to dropping non significant traffic, like the millions of ICMP (ping) request/replies.

        The resultant will be : your WAN goes down for a reason that has nothing to do with your connection.

        My advise is : use a more close to you IP to test against, typically an upstream gateway.

        Note : still, if something goes bas on your direct uplink connection, then you will see the same ICMP packets from Google not coming back neither. That 's why you should choose an IP 'to ping' as close as possible.

        Also, your ISP maintain your uplink and the quality of it. You, as a client, can't do nothing more as "notifying" them.

        No "help me" PM's please. Use the forum, the community will thank you.
        Edit : and where are the logs ??

        1 Reply Last reply Reply Quote 1
        • L Offline
          LMM
          last edited by LMM

          Thank you very much for your clear explanation.
          If I understand well, I must change my WAN Monitor IP to a closer one to me.
          So, in "Monitor IP Interface WAN_DHCP Gateway" , I change the IP address to 109.51.0.1

          Let me see how it behaves.

          Thank you very much again.
          Best regards,
          Miguel

          1 Reply Last reply Reply Quote 0
          • L Offline
            LMM
            last edited by

            The result, after 2 hours

            b0444fd4-91ef-40da-a4df-fec05850c0f0-imagem.png

            Aug 2 11:37:04 dpinger WAN_DHCP 109.51.0.1: Alarm latency 9593us stddev 249us loss 21%

            Aug 2 11:38:33 dpinger WAN_DHCP 109.51.0.1: Clear latency 9628us stddev 264us loss 9%

            1 Reply Last reply Reply Quote 0
            • GertjanG Offline
              Gertjan
              last edited by

              You saw the monitor graph called Quality - select the WAN interface ?

              It's probably your direct uplink, which mans : only your ISP can help you.

              No "help me" PM's please. Use the forum, the community will thank you.
              Edit : and where are the logs ??

              1 Reply Last reply Reply Quote 1
              • L Offline
                LMM
                last edited by

                Thank you for your support.
                I will check the wan quality graph and report to my ISP.
                Do you know why the router provided by them, don't lose the connection? Is their equipment prepared to accept the "bad" connection quality?

                Best regards

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