System log tun_wg0: loop detected
-
@stephenw10 said in System log tun_wg0: loop detected:
It shouldn't be unless you have something bridged. That only governs where/how the firewall rules are applied.
I checked the system log again today, and found tons of the same message (tun_wg0: loop detected).
I have nothing bridged (i.e. under interfaces -- bridges, there is nothing listed)
Is there anything else I can check to shed some light on this?
FWIW, the WG connections appear to be functioning just fine, even when these messages are appearing in the log.
-
That log message is generated by this:
https://github.com/pfsense/FreeBSD-src/blob/RELENG_2_5_2/sys/net/if.c#L4010So I would expect it's because you have somehow configured some sort of recursion. Like maybe a peer endpoint inside the tunnel interface subnet.
Steve
-
Not exactly sure what that means. But my configuration is:
"Wireguard" interface (OPT1) is assigned to tun_wg0 with static IPv4 192.168.133.1/24
Peers are (manually) assigned IP addresses between 192.168.133.20 through 192.168.133.60
DNS is 192.168.133.1
What would be the source of the recursion? -
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
-
@stephenw10
Understood. So does that help to identify the source of the loop? I am not sure where I messed up. -
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.
-
@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? -
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
-
@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 ZZZDoes that help identify the source of the loop?
-
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. -
@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?
-
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
-
@stephenw10
Now I get it. I have made that change.
Thank you for working this through with me - really appreciate the help! -
No problem. Been a while since I revisited some of that.
-
P pfguy2018 referenced this topic on
-
S stephenw10 referenced this topic on
-
@stephenw10 thank you for your wisdom.
@pfguy2018 thank you for asking.
