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

    System log tun_wg0: loop detected

    Scheduled Pinned Locked Moved General pfSense Questions
    22 Posts 3 Posters 3.0k 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.
    • stephenw10S
      stephenw10 Netgate Administrator
      last edited by

      The peers can have an IP that's inside the subnet as long as that's not the end point IP. Each peer doesn't really care about other other peers IP since routing is all done on the keys.

      Steve

      P 1 Reply Last reply Reply Quote 0
      • P
        pfguy2018 @stephenw10
        last edited by

        @stephenw10
        Understood. So does that help to identify the source of the loop? I am not sure where I messed up.

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

          Normally the remote access style you have doesn't have endpoints set for the peers. They are are set as dynamic. So that wouldn't apply.

          P 1 Reply Last reply Reply Quote 0
          • P
            pfguy2018 @stephenw10
            last edited by

            @stephenw10
            Oh - could that be the issue then? Should I be setting them all to dynamic? If I do that, do I have to enable the DHCP server on the Wireguard interface?

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

              No, normally clients are statically configured with an IP within the 'tunnel subnet'.

              See: https://docs.netgate.com/pfsense/en/latest/recipes/wireguard-ra.html

              Steve

              P 1 Reply Last reply Reply Quote 0
              • P
                pfguy2018 @stephenw10
                last edited by

                @stephenw10
                Those are the exact instructions I followed. I am getting confused here. For my setup, what is the difference between "peers" (which you said should have a dynamic address) and "clients" (which you said should have a static address)?

                In case it matters, the devices connecting remotely are configured as follows:

                [Interface]
                PrivateKey = XXX
                ListenPort = 51820
                DNS = 192.168.133.1
                Address = 192.168.133.20/32 (for example - each device has a different IP)

                [Peer]
                PublicKey = YYY
                AllowedIPs = 0.0.0.0/0
                Endpoint = dynDNS address to my pfSense install (dynamic.example.com:51820)
                PSK enabled ZZZ

                Does that help identify the source of the loop?

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

                  That's fine.

                  The 'client' peers endpoint should be set as dynamic at the 'server' end.
                  But set as a static IP in the tunnel subnet at the client itself.

                  P 1 Reply Last reply Reply Quote 0
                  • P
                    pfguy2018 @stephenw10
                    last edited by

                    @stephenw10 said in System log tun_wg0: loop detected:

                    The 'client' peers endpoint should be set as dynamic at the 'server' end.

                    You mean on pfSense-VPN-WireGuard-Peers, under each peer, the box for "dynamic endpoint" should be checked?

                    I can do this, but I was hoping to have rules applied to different groups of peers. i.e. the "admin" group (my devices) with addresses 192.168.133.20-192.168.133.29 are allowed to access LAN addresses through the VPN. Peers with addresses outside this range are blocked from LAN access, and can only tunnel through to the web.

                    Can that still be accomplished if I use dynamic addresses? Will setting the IP address as static in the client WG install take care of this?

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

                      Yes that should be checked. You only add an IP there if the peers have a static public IP which is very unlikely in a 'road warrior' scenario.
                      If you have added the internal private IP of each peer there that is telling the server end to connect the tunnel to the peer across it's existing tunnel! Hence the recursion and loop error.

                      Steve

                      P 1 Reply Last reply Reply Quote 0
                      • P
                        pfguy2018 @stephenw10
                        last edited by

                        @stephenw10
                        Now I get it. I have made that change.
                        Thank you for working this through with me - really appreciate the help!

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

                          No problem. Been a while since I revisited some of that. 😉

                          tylereversT 1 Reply Last reply Reply Quote 0
                          • P pfguy2018 referenced this topic on
                          • stephenw10S stephenw10 referenced this topic on
                          • tylereversT
                            tylerevers @stephenw10
                            last edited by

                            @stephenw10 thank you for your wisdom.
                            @pfguy2018 thank you for asking.

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