Messages

Have you thought about port forwarding on your router? Incoming requests on the WG port need to be directed to the WG host

Great. One other thing you might want to check is how DNS is being handled. If your NAS is already using a public DNS such as Cloudflare and you are happy to continue with that for the tunnel, probably nothing more to do. The requests should be going via the tunnel.

My case is a little different. I run Pi-Hole and unbound on a RPi that provides DNS to my network. Given that is on a local IP, it is not routed through the tunnel in the setup I previously outlined (since local IPs are excluded from being passed through the tunnel). I will have to figure out how to deal with that. I probably first need a firewall rule that sends DNS packets from the iPhone destined for the RPi instead through the tunnel, and then also some form of NAT rule that translates those packets from the RPi IP to an IP in the tunnel (possibly the gateway IP, or the local tunnel IP?) so that the DNS servers configured in WG are used.

But that will break local DNS resolution. My current OpenVPN setup for another host in my LAN has split DNS implemented which deals with that issue. Not sure whether that is currently possible with a WG setup. Hmmm...

Quite possibly a routing issue as you have guessed. I haven't implemented WG on a host behind my firewall, only on the OPNsense firewall itself, so haven't got any immediate ideas for your scenario

Try changing the AllowedIPs to CIDR notation, eg 192.168.5.1/32

You likely need a firewall rule incoming on wg1 from your phone's tunnel IP to your LAN

A somewhat longer version of mimugmail's summary is here:
https://r.tapatalk.com/shareLink/topic?share_fid=197904&share_tid=20413&url=https%3A%2F%2Fforum%2Eopnsense%2Eorg%2Findex%2Ephp%3Ftopic%3D20413&share_type=t&link_source=app

See from post #4 onwards. Although in addition to mimugmail's summary I found an outbound NAT rule to be necessary

Oh, and in the NAT outbound rule I only included the single iPhone IP, not the whole LAN network.

[mention]trevs [/mention] Did you have any luck getting this to work?

I had a go over the weekend setting up a WG tunnel with PIA, and it seemed to work. I was able to tunnel just the (IPv4) IP of my iPhone over the tunnel, and the rest of my network seemed unaffected.

I essentially followed the guide posted by Jonny on imgur, although I didn't bother with the firewall rule to allow all other LAN clients out of the normal WAN gateway, as I figured the standard "allow LAN to any" rule would deal with that. I just had to make sure that the rule for the iPhone IP was above that standard rule.

I also didn't try the "kill switch" settings as this was only a test run. When I eventually switch from OpenVPN to WG to PIA I will likely do that, and also deal with IPv6. In my test my IPv6 address from my iPhone was leaking out of the normal WAN gateway as I had not addressed IPv6.

How I interpret those rules is:

• if a packet comes into the LAN interface from the single IP 192.168.2.102 and is not destined for another IP on the local network, then allow that packet out via the WG (external) gateway
• otherwise, if a packet comes into the LAN interface from any other IP and is not destined for another IP on the local network, then allow that packet out via the normal WAN gateway

Which is what you are trying to achieve, correct?

Order of the rules is important.

Disclaimer: I haven't configured Wireguard with a commercial VPN provider at this stage (still using OpenVPN with PIA), so I don't have first hand experience of doing this (yet).

But gut feel is that there is something not right with your FW rules.

Have you seen this? https://imgur.com/gallery/JBf2RF6

Gives an example of routing only 1 IP through the tunnel. I think creating the WG gateway is required so that you can do the more complicated routing.

Maybe you can adapt the guides in this thread - particularly in post #29:

https://r.tapatalk.com/shareLink/topic?share_fid=197904&share_tid=15105&url=https%3A%2F%2Fforum%2Eopnsense%2Eorg%2Findex%2Ephp%3Ftopic%3D15105&share_type=t&link_source=app

Nevermind, it was my own stupidity - when I turned IPv6 back on for the WAN, the settings defaulted to a /64 prefix, rather than the /56 that my ISP provides. So OPNsense thought it had nothing to hand out to the VLANs. Fixed now! ::)

Hopefully sometime can give me a tip to fix a little problem I have with IPv6.

Up until yesterday, I had IPv6 configured properly in OPNsense. My various VLANs were getting /64 networks, and all was good.

My ISP developed some IPv6 routing issues yesterday due to some router config changes at their end, and while they were fixing it I turned off IPv6 on the WAN interface (didn't touch the VLANs though).

Today I turned it back on. However, my VLANs are no longer getting /64s.

The WAN is happily getting an /128 address and /56 prefix. But dhcp6c says in the logs for each VLAN, for example: "failed to add an address on igb1: File exists".

Reloading IPv6 on the WAN does not fix it. Nor does restarting radvd. Nor does rebooting OPNsense.

Anyone got any tips for fixing this easily? Thanks.

Loose language, my bad. My point was simply it is not always immediately obvious that a handshake has failed

You don't put the same public key in both local and endpoint. The local public key corresponds to the local private key (and would have been autogenerated when you created the local config). The local public key is what you give to the peer (Torguard in your case?). The endpoint public key is what you are given by the peer (Torguard).

Your traffic stats suggest that no VPN connection is being made - the thing about WG is that it doesn't expressly tell you if a connection has failed; I guess a short codebase doesn't leave room for error reporting lol.

BTW, you can packet capture under Interfaces->Diagnostics->Packet Capture.