@bob-dig

It works! Thanks!

@ben9090 Good that it's working but if you want to troubleshoot the pings, do packet captures on all relevant ports to see where they're getting lost.

@brians Thank you so much that exactly what i needed it worked perfectly

@rcoleman-netgate Oh I remember that now how it shares one internal interface for everything.

I have since been able to reproduce the issue, having the same problem but less setup:

Install the package Set up the tunnel (Assign interface, configure a peer) Set up a WAN-Rule to allow connections and do a test. Done

After the pfsense is rebooted, my WAN-Gateway for ipv4 goes down (Services -> Gateways) and the firewall is not able to do an ipv4 based update-check or ipv4 based ping (using Select Interface automatically). Everything works using ipv6, I tested the ipv4 functionality using the context switch in Advanced setup -> Networking.

On the other hand, certain ipv4 services still work, namely:

name resolution using ipv4 pinging, if the WAN-interface is explicitly chosen

Disabling wireguard does not solve the issue, uninstalling and rebooting does though. Logs give no hint as of why this issue arises. Does anybody have an idea? Or shall I issue a github-issue to the corresponding wireguard-plugin?

@dapersico post a screenshot of your rules please.

And do you have any rules in your floating tab?

That looks like it was evaluated with that 0/4.. But to be honest, why would the client even try to be connecting to your lan address, that would never work from the internet. So its prob going to your wan address.

Which is why I suggested use "this firewall" alias - this would be all your pfsense IPs..

@tommyt619

Update: Nope! I was wrong. Well, I was right about my mistake at least. Thankfully I hadn't deleted the line in wg0.conf because I probably would have assumed that I tried and it failed. Since I'm split tunneling Ive got a million different networks and staring right at me on the next line is #0.0.0.0/24. Facepalm. 0.0.0.0/0 now works. nftables handling NAT from there to all the VLANs so all is well.

Thanks again!

@siwatsirichai
I think you are handling this wrong but depends on your use case.

Site B,C,D will have the real IP of the client natted - Assuming this is what you want.

If this is not what you want, then have no gateway configured for the WireGuard Interface at site B,C,D. You then need to create a gateway at each site and for each site then you utilize static routing.

@jarhead Yes! This worked. Thank you so much

@johnpoz

Thanks - but that gave the same error. I think the root of my problem is that VirginMedia hate VPNs!

https://windowsreport.com/vpn-blocked-virgin/

I think I will try accessing the site sometime when on another isp!

Thanks again - must go battery very low.

If you haven’t solved your issue yet, you have to request an IP without DNS hijacking from a different API. If you want to use the WG key you are currently using, delete it from your Mullvad account and then request the IP. You can also just use a new key if you prefer. The guide I linked below will show you how to request the IP that does not have DNS hijacking. After setting your tunnel up with the new IP Unbound will work through the Mullvad tunnel. Just an FYI, Mullvad’s connection test will show a DNS leak while using Unbound. As long as the test shows that your DNS IP is exactly the same as your tunnel’s public IP then it is working.

link text

@bob-dig

ok! looks like the chatty kathys have stopped. Not seeing any traffic on the WG interface.

Thank you Sir!!

@ryu945 I tried VPNing from outside the network and I couldn't get internet at all for wireguard.

@xxgbhxx said in Strange Wireguard Setup Problem:

So your issue I think is caused by your OpenVPN tunnel acting as the default route.

This ended up being the issue. Even though my Pfsense configuration said wireguard interface was the default route, I had to force it to WAN. Now it works fine. Now that I had forced it to WAN one time, I find wireguard is connecting fine whether I have the default route set to WAN or the wireguard interface. This is strange that wireguard as default route works now when it didn't before and I suspect it is related to some underlying bug. From my experience with 2.6.0 so far, I have noticed things acting buggy. It is the first time I had a configuration fail to apply. I think I was apply a DNS resolver configuration and I had to apply a different configuration before I could apply the one I intended to as clicking save and reapply did not reapply it. This version of Pfsense feels like it should had stayed in the development branch for longer.

@johnpoz , I would be my grandma 😀

Why they don't just let you put in the IP or the fqdn for your devices is beyond me.<

Only God knows....

Just control your iot devices via their mother ship website ;)<

There's an option called "Out of Home" or something similar... but looking at their own beautiful protocol, it seems that these weird devices don't need any strong authentication to set options..so in the worst case I will control them just from home just from their lan..

Just looking for a situation where WireGuard might not work, maybe a port is blocked, TCP versus UDP, streaming video files, using in Europe, Asia, etc.,