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

    [retitled] ATT BGW320 IP Passthrough thrashes following 23.09 update, then settles

    Scheduled Pinned Locked Moved
    General pfSense Questions
    3
    7
    839
    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.
    • M
      marcg
      last edited by marcg

      After upgrading to 23.09 (GA) from 23.05.1, wireguard clients can no longer connect.

      • Upgraded to 23.09 from the GUI while watching the serial console. Didn't see anything unusual in either.
      • Running Wireguard 0.2.1.
      • Reinstalling the package from the package manager didn't help.
      • Restoring the router config from immediately before the upgrade didn't help.
      • php_wg is running. wg show all and the GUI's Wireguard status/settings pages look correct.
      • When booting with the old 23.05.1 boot environment, Wireguard again works
      • Nothing obviously relevant in the logs except for the following which appears every time Wireguard starts. Still running the old-school ISC DHCP. The router is running v4+v6 dual stacked, but Wireguard is only configured to route v4.

      Nov 7 11:07:13 pfSense php_wg[44386]: /usr/local/pkg/wireguard/includes/wg_service.inc: The specified range lies outside of the current subnet. Skipping DHCP6 entry.

      Suggestions very welcome.

      Upgrade was otherwise smooth.

      1 Reply Last reply Reply Quote 0
      • M
        marcg
        last edited by marcg

        Issue resolved for now. It's related to the Block Bogon Networks option in the WAN interface config and associated firewall rule. I thought to look at the WAN config as there were also issues with other connections initiated from the WAN.

        I had Block Bogon Networks enabled in 23.05.1. That config carried over to 23.09 in the upgrade. After the upgrade, Wireguard and inbound ssh (DNAT'ed to an internal machine) to the router's public IP stopped working. I turned the bogon blocking off, inbound Wireguard and ssh started working. Turned bogon blocking back on, both stopped working. I repeated this on/off several times with repeatable results. But now, a couple of hours after the upgrade, both are working with bogon blocking on 🤷

        So, there's something amiss with bogon blocking. Maybe having to do with bogon table updates following an upgrade.

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

          Hmm, odd. That rule only blocks traffic from sources on the bogons list. Maybe you were testing from something unusual.

          M 1 Reply Last reply Reply Quote 0
          • jimpJ jimp moved this topic from Problems Installing or Upgrading pfSense Software on
          • M
            marcg @stephenw10
            last edited by marcg

            @stephenw10 thanks for the response. Turns out that I was testing from something unusual, but not intentionally!

            The bridged connection between my ISP gateway and the pfSense WAN interface thrashed for ~2.5 hours following the upgrade. During most of that period, the pfSense had an address on the gateway's LAN (192.168.1.0/24) rather than a routeable address. Access to inbound services from the Internet would have been blocked during those periods.

            The gateway is an ATT BGW320 running in IP Passthrough mode (bridge-like and locked to the pfSense's WAN MAC, BGW320 FW 4.25.4). Yesterday was the first hiccup I've seen with this setup in two years. It's been stable now for ~18 hours. I haven't touched the relevant config on either side in many months.

            pfSense dhclient logs below with A.B.C.D for my public address. The upgrade happened around 10 AM local. The problems resolved around 12:50. The pfSense WAN had the wrong IP for ~2 hours of that period.

            The bogon blocking results described above were real. The only way I can make sense of them is that, by chance, I was enabling/disabling the bogon blocking in sync with the WAN address flaps.

            Nov  7 09:56:39 pfSense dhclient[6188]: bound to A.B.C.D -- renewal in 300 seconds.
Nov  7 10:01:40 pfSense dhclient[6188]: bound to A.B.C.D -- renewal in 300 seconds.
Nov  7 10:05:11 pfSense dhclient[38166]: bound to A.B.C.D -- renewal in 300 seconds.
Nov  7 10:12:38 pfSense dhclient[24242]: bound to 192.168.1.66 -- renewal in 43200 seconds.
Nov  7 11:06:13 pfSense dhclient[20709]: bound to 192.168.1.66 -- renewal in 43200 seconds.
Nov  7 11:46:05 pfSense dhclient[37818]: bound to A.B.C.D -- renewal in 300 seconds.
Nov  7 11:49:49 pfSense dhclient[20412]: bound to 192.168.1.66 -- renewal in 43200 seconds.
Nov  7 12:18:16 pfSense dhclient[66148]: bound to A.B.C.D -- renewal in 300 seconds.
Nov  7 12:21:33 pfSense dhclient[68762]: bound to A.B.C.D -- renewal in 300 seconds.
Nov  7 12:26:33 pfSense dhclient[68762]: bound to A.B.C.D -- renewal in 300 seconds.
Nov  7 12:31:33 pfSense dhclient[68762]: bound to A.B.C.D -- renewal in 300 seconds.
Nov  7 12:36:33 pfSense dhclient[68762]: bound to A.B.C.D -- renewal in 300 seconds.
Nov  7 12:39:19 pfSense dhclient[35430]: bound to A.B.C.D -- renewal in 300 seconds.
Nov  7 12:42:30 pfSense dhclient[19349]: bound to A.B.C.D -- renewal in 300 seconds.
Nov  7 12:46:01 pfSense dhclient[21660]: bound to 192.168.1.66 -- renewal in 43200 seconds.
Nov  7 12:49:02 pfSense dhclient[98031]: bound to A.B.C.D -- renewal in 300 seconds.
Nov  7 12:51:31 pfSense dhclient[39824]: bound to A.B.C.D -- renewal in 300 seconds.
Nov  7 12:54:20 pfSense dhclient[19743]: bound to A.B.C.D -- renewal in 300 seconds.
Nov  7 12:59:20 pfSense dhclient[19743]: bound to A.B.C.D -- renewal in 300 seconds.
Nov  7 13:00:08 pfSense dhclient[54857]: bound to A.B.C.D -- renewal in 300 seconds.
            1 Reply Last reply Reply Quote 2
            • V
              vrmike
              last edited by

              Hello guys,

              I have the same problem.
              Since the update, the ISP gateway has a local IP address, Wireguard clients cannot establish a connection.
              Is there a solution to the problem?
              Sorry for my bad English.

              Greetings Mike

              M 1 Reply Last reply Reply Quote 0
              • M
                marcg @vrmike
                last edited by marcg

                @vrmike in my case, the ISP gateway is upstream of the pfSense. The gateway had a public WAN address but was (for a short period) assigning an incorrect DHCP address to the pfSense.

                Have you tried rebooting both boxes, ISP gateway followed by pfSense?

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

                  Yes, the gateway IP doesn't actually matter. For example my ISP here uses a private IP for the gateway but the WAN IP is public which is common for PPPoE.

                  For other connection types though the gateway is almost always in the WAN subnet which implies if you see a private IP on the gateway you probably also have one on the WAN.
                  If you see that it means something upstream is NATing the connection so incoming connections to the firewall would have to be forwarded through it.

                  But even then the block bogons and block private subnets rules would not block traffic from remote clients.

                  1 Reply Last reply Reply Quote 1
                  • First post
                    Last post