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

    Handshakes fail indefinitely until changing listen port after WAN reset - possible repeat bug?

    Scheduled Pinned Locked Moved WireGuard
    9 Posts 3 Posters 997 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.
    • B
      brswattt
      last edited by

      Hello,

      I am on PfSense plus 22.05. I have 3 wireguard tunnels running. Last night around 2 AM my wan dhcp lease renewed, and at that same time my wireguard tunnels all went down (I got a notification from my monitor). so I rebooted, still nothing. I reinstalled wireguard, nothing. I saw that states in the table to the endpoints on those ports, but gateways were still down. I thought it was maybe my custom AT&T DHCPv6 config, so I disabled ipv6 completely, nothing. As soon as I changed the listen ports on all of the tunnels, they started handshaking again.

      This was the issue I was referencing:
      https://redmine.pfsense.org/issues/12399

      Does anybody have any insight?

      Bob.DigB 1 Reply Last reply Reply Quote 0
      • Bob.DigB
        Bob.Dig LAYER 8 @brswattt
        last edited by

        @brswattt Your talking about incoming or outgoing tunnels? Maybe it is just a DNS problem?

        B 1 Reply Last reply Reply Quote 0
        • B
          brswattt @Bob.Dig
          last edited by

          @bob-dig Outgoing tunnels, with their endpoints specified via IP.

          J 1 Reply Last reply Reply Quote 0
          • J
            Jarhead @brswattt
            last edited by

            @brswattt Wireguard doesn't have incoming or outgoing tunnels, they're all just peers.

            Changing the listening ports, meaning you selected different ports on both ends?
            Were the 'old' ports still open on the WAN?

            B 1 Reply Last reply Reply Quote 0
            • B
              brswattt @Jarhead
              last edited by

              @jarhead No not on both ends. My peer ports still stayed the same at 51820 but my tunnel listening ports on my end were changed. I have ports open on my WAN side (51820-51825) for remote access when away from home. Those ports are the same I was using for my listening ports for my other tunnels actually.....now that I think about it, that sounds like a problem.

              J 1 Reply Last reply Reply Quote 0
              • J
                Jarhead @brswattt
                last edited by

                @brswattt Yeah, probably lucky they worked at all.
                Set the tunnel ports to the same as the peer ports for each tunnel. ie if you have two peers on one tunnel, and the tunnel uses 51821, both peers need to use 51821 also.
                And you can no longer use 51821 for any other tunnels or peers.

                B 1 Reply Last reply Reply Quote 0
                • B
                  brswattt @Jarhead
                  last edited by brswattt

                  @jarhead Well, I have 2 Mullvad tunnels up with two separate peers. and put them in a gateway group in case one of them goes down. Mullvad tunnels all have the same endpoint port (51820, that's how Mullvad sets them up) how do multiple peers work in PfSense? Can I have two separate mullvad peers on one tunnel? How does it determine which peer to route through?

                  Bob.DigB 1 Reply Last reply Reply Quote 0
                  • Bob.DigB
                    Bob.Dig LAYER 8 @brswattt
                    last edited by

                    @brswattt Use different Ports on your side... Also there is a video.

                    B 1 Reply Last reply Reply Quote 0
                    • B
                      brswattt @Bob.Dig
                      last edited by

                      @bob-dig yes, I am now using different listen ports on the 2 mullvad tunnels. Hopefully that resolves the issue.

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