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

    2.7.0 PPPoE not routing traffic

    Scheduled Pinned Locked Moved General pfSense Questions
    16 Posts 3 Posters 1.7k Views
    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.
    • T
      threadhead @stephenw10
      last edited by

      @stephenw10 Sorry for the late reply.

      To be clear, I reverted pfSense back to 2.6.0 so all the info I'm discussing is running 2.6.0 and NOT 2.7.0.

      Ran pcap on WAN and I see plenty of traffic going in/out of the WAN. I see the correct IP address for PPPoE.

      I checked states and I do see traffic routing to WAN/PPPoE.

      I checked and the default route is PPPoE (WAN).

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

        Hmm, well it should be identical in 2.6 and 2.7 although there are some changes there.

        So pfSense itself is still failing to ping out to, say, 1.1.1.1?

        T 1 Reply Last reply Reply Quote 0
        • T
          threadhead @stephenw10
          last edited by

          @stephenw10 On 2.7.0 yes. On 2.6.0 works fine.

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

            Hmm, I think you're going to have to upgrade to 2.7 again and check the routes, states, interfaces etc. We need more info to know what's failing.

            1 Reply Last reply Reply Quote 0
            • D
              dipeshrestha
              last edited by

              I am also having the same issue with 2.7.

              I will check the gateway, traffic/pcap via wan when the issue reappears. I can replicate the issue but need appropriate time to do so. Will update soon.

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

                It doesn't happen every time for you then? What do you do to replicate it?

                1 Reply Last reply Reply Quote 0
                • D
                  dipeshrestha
                  last edited by

                  Hi Stephen

                  I can replicate the HFC NTD reset by using a bandwidth-on-demand service. Every time I change my Internet bandwidth, the ISP modem will sync with HFC CMTS bringing down pppoe link.

                  Setup:
                  HFC Cable ---> Arris HFC NTD ------> PFSENSE ----> Wifi device ----> Internal LAN.

                  I replicated the scenario and my finding as below: All time in Australian Eastern Standard time (AEST)
                  My observation is pfsense is kind of blocking all LAN traffic toward WAN interface. Once I Normal Reboot the pfsense, everything will start to work. This happened after upgrading to 2.7.

                  Sorry for the long post.

                  link down at 5:35pm

                  Jul 29 17:35:30 ppp 12904 [wan_link0] LCP: no reply to 4 echo request(s)
                  Jul 29 17:35:20 ppp 12904 [wan_link0] LCP: no reply to 3 echo request(s)
                  Jul 29 17:35:10 ppp 12904 [wan_link0] LCP: no reply to 2 echo request(s)
                  Jul 29 17:35:00 ppp 12904 [wan_link0] LCP: no reply to 1 echo request(s)
                  Jul 28 05:10:43 ppp 12904 [wan] IFACE: Add description "WAN"
                  Jul 28 05:10:43 ppp 12904 [wan] IFACE: Rename interface ng0 to pppoe0

                  ==================================
                  PPPoE UP in pfsense

                  Jul 29 17:36:02 ppp 12904 [wan] IFACE: Add description "WAN"
                  Jul 29 17:36:02 ppp 12904 [wan] IFACE: Rename interface ng0 to pppoe0
                  Jul 29 17:36:02 ppp 12904 [wan] IFACE: Up event
                  Jul 29 17:36:01 ppp 12904 [wan] 111.222.55.35 -> 111.222.1.9
                  Jul 29 17:36:01 ppp 12904 [wan] IPCP: LayerUp
                  Jul 29 17:36:01 ppp 12904 [wan] IPCP: state change Ack-Sent --> Opened
                  Jul 29 17:36:01 ppp 12904 [wan] SECDNS 111.222.0.4
                  Jul 29 17:36:01 ppp 12904 [wan] PRIDNS 111.222.0.3
                  Jul 29 17:36:01 ppp 12904 [wan] IPADDR 111.222.55.35
                  Jul 29 17:36:01 ppp 12904 [wan] IPCP: rec'd Configure Ack #15 (Ack-Sent)

                  ==================================
                  Packet capture in pfsense LAN interface (while pinging 1.1.1.1)
                  17:41:56.902001 IP 192.168.20.83 > 1.1.1.1: ICMP echo request, id 1, seq 2391, length 40
                  17:41:56.902033 ARP, Request who-has 1.1.1.1 tell 192.168.20.1, length 28
                  17:42:01.903371 IP 192.168.20.83 > 1.1.1.1: ICMP echo request, id 1, seq 2392, length 40
                  17:42:01.903403 ARP, Request who-has 1.1.1.1 tell 192.168.20.1, length 28
                  17:42:06.899092 IP 192.168.20.83 > 1.1.1.1: ICMP echo request, id 1, seq 2393, length 40
                  17:42:06.899125 ARP, Request who-has 1.1.1.1 tell 192.168.20.1, length 28

                  ==================================
                  Packet capture in pfsense WAN interface (while pinging 1.1.1.1)
                  No packet captured

                  ==================================
                  Packet capture in WAN (everything) (i can provide pcap file if you want)

                  17:44:44.506531 IP 111.222.0.3.53 > 111.222.55.35.6767: UDP, length 125
                  17:44:44.511378 IP 111.222.0.3.53 > 111.222.55.35.40457: UDP, length 167
                  17:44:44.751708 IP 111.222.55.35 > 111.222.1.9: ICMP echo request, id 62547, seq 412, length 9
                  17:44:44.761723 IP 111.222.1.9 > 111.222.55.35: ICMP echo reply, id 62547, seq 412, length 9
                  17:44:45.243559 IP 111.222.55.35.45293 > 111.222.0.3.53: UDP, length 44
                  17:44:45.243724 IP 111.222.55.35.16248 > 111.222.0.3.53: UDP, length 44
                  17:44:45.253082 IP 111.222.0.3.53 > 111.222.55.35.45293: UDP, length 155
                  17:44:45.258508 IP 111.222.0.3.53 > 111.222.55.35.16248: UDP, length 187
                  17:44:45.261962 IP 111.222.55.35 > 111.222.1.9: ICMP echo request, id 62547, seq 413, length 9
                  17:44:45.271783 IP 111.222.1.9 > 111.222.55.35: ICMP echo reply, id 62547, seq 413, length 9
                  17:44:45.423125 IP 64.62.197.155.50659 > 111.222.55.35.8090: tcp 0
                  17:44:45.555388 IP 162.142.125.239.40577 > 111.222.55.35.57497: tcp 0
                  17:44:45.764512 IP 111.222.55.35 > 111.222.1.9: ICMP echo request, id 62547, seq 414, length 9
                  17:44:45.775251 IP 111.222.1.9 > 111.222.55.35: ICMP echo reply, id 62547, seq 414, length 9
                  17:44:46.285826 IP 111.222.55.35 > 111.222.1.9: ICMP echo request, id 62547, seq 415, length 9
                  17:44:46.296962 IP 111.222.1.9 > 111.222.55.35: ICMP echo reply, id 62547, seq 415, length 9

                  ==================================

                  Part of Firewall State table:
                  LAN tcp 192.168.20.65:56997 -> 104.18.3.35:443 CLOSED:SYN_SENT 2 / 0 104 B / 0 B
                  LAN tcp 192.168.20.65:56997 -> 104.18.3.35:443 SYN_SENT:CLOSED 2 / 0 104 B / 0 B
                  LAN tcp 192.168.20.83:53710 -> 65.8.134.38:443 CLOSED:SYN_SENT 2 / 0 104 B / 0 B
                  LAN tcp 192.168.20.83:53710 -> 65.8.134.38:443 SYN_SENT:CLOSED 2 / 0 104 B / 0 B
                  LAN tcp 192.168.20.65:56998 -> 104.18.3.35:443 CLOSED:SYN_SENT 2 / 0 104 B / 0 B
                  LAN tcp 192.168.20.65:56998 -> 104.18.3.35:443 SYN_SENT:CLOSED 2 / 0 104 B / 0 B
                  LAN udp 192.168.20.250:58336 -> 111.222.0.3:53 SINGLE:MULTIPLE 1 / 1 67 B / 118 B

                  ==================================

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

                    @dipeshrestha said in 2.7.0 PPPoE not routing traffic:

                    17:41:56.902033 ARP, Request who-has 1.1.1.1 tell 192.168.20.1, length 28

                    Check the routing table. It thinks 1.1.1.1 is in the same subnet as one of it's interfaces so something there probably has a very wrong subnet mask.

                    D 1 Reply Last reply Reply Quote 0
                    • D
                      dipeshrestha @stephenw10
                      last edited by

                      @stephenw10 Isn't it an issue of pfsense. why should it send arp request for 1.1.1.1. This network is not in the routing table and should be forwarded to default gateway as per the rule.

                      I downgraded to 2.6 and there is no issue.

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

                        I assume 192.168.20.1 is the pfSense LAN IP? It would only send an ARP request for 1.1.1.1 there if it thinks it has an IP in the same subnet as that. So at least when it was sending that ARP request it must have had a bad route present somehow.

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