Masquerading on the lan could be responsible for the issue.
I shall turn it it off then.
I think I've solved it!
Fail2ban on docker-mailserver had my LAN listed, I should have thought of it sooner. thanks again for your patience @psherman .
I'll go through and test out wireguard access again tomorrow and make sure it all resolves correctly still. Need to pass out now.
hey @psherman I was traveling countries and indeed that fix I discovered was what was causing the email problem.
I swapped phones recently and so had the occasion to do some more testing re: wireguard working on the phones but not the laptop. I made some really weird discoveries so I'm dumping it here in case it helps diagnose what's wrong with my setup.
So one of the ways I've been utilizing the vpn while traveling is merely turning on a wifi hotspot from my phone, enabling 'Allow clients to use VPNs' on android and then turning on the wireguard vpn from my phone and connecting to it as a hotspot from the laptop. This works perfectly.
What I recently discovered while migrating phones is this works perfectly even when the phone is just on a wifi network and no cellular modem / mobile data connection is engaged. Which seems to rule out this being a lan-to-lan numbering scheme like we've been discussing (as far as I can tell the wifi here is of the same 192.168.1.x as a SOHO / commodity network).
This technique works for the laptop to use the cells vpn / hotspot successfully on both mobile data or solely wifi.
Still however the laptop's wireguard client configuration continues to not function properly. It will get the correct endpoint IP (just simple testing like whatismyip.com) but cannot access any of the lan's resources like when using the mobile connection.
I believe I have solved it,
on re-reading this thread I re-added
AllowedIPs = 192.168.1.0/24, 0.0.0.0/0, ::/0
and now can route to all internal lan destinations. The change I made was to prioritize the 192 entry ahead of the catch-all 0.0.0.0
1 Like
That is great news. What you have found is a quirk of wireguard on windows. I suspect that the windows routing tables behave very differently than Linux.
config zone
option name 'wg'
option input 'ACCEPT'
option output 'ACCEPT'
option forward 'ACCEPT'
option family 'ipv4'
list network 'wg0'
option masq '1'
heh, of course somehow you made this zone, but then didn't...
option mtu_fix '1'
even though it's a almost a certainty the mtu for this vpn will be below 1500 
I'm only running Linux systems. Specifically this is Pop_OS! 22.04.
I'm unsure if your reply is intended as a specific piece of advice or merely commenting some sort of technical joke / sarcasm, as it seems bereft of any explanation that would be helpful to me.
While I'd normally be tempted to thank anyone for a meaningful contribution to the thread......yours really isn't, at least AFAI can tell.
So I guess I just won't. 