Wireguard firewall rules issue

[edickens]

Hi,

New to opnsense so apologies if this has been asked and link to where I might find it would be appreciate. I am setting up an unusual configuration at least in my opinion. I have a wireguard "server" at one location that needs to be connected to. The other end is opnsense to route a specific subnet across it. I have gotten the connection setup handshake confirmed and can ping the remote network using opnsense diagnostic tools no lost packets. All good there. I have also tested the remote connection with a different client on a laptop. When I try to access the remote network from the local LAN I get nothing. Firewall rules do confirm the request is going out properly. I have to assume it's in my internal firewall rules.

 Rules currently setup
LAN interface: direction in, protocols all, ports all, source Remote LAN, destination Local LAN
Wireguard interface: direction in, protocols all, ports all, source Remote LAN, destination Local LAN
WAN: direction in, protocols all, ports all, source Remote public IP, destination Local public IP

I have looked at variety of sources ranging from the Site to Site documentation forum posts of other issues to in desperation an AI chatbot.

Any help is appreciated

[edickens]

After some more investigation it appears that the issue seems to be that traffic is being sent to the wireguard interface, but not through the wireguard tunnel if that is possible.

Any help is appreciated. Thank you

[viragomann]

Is you LAN subnet added to the allowed subnets in the remote WG settings?

[edickens]

It wasn't until a little bit ago when I had an AHA moment. That still didn't fix the problem. It was after that when I noticed in the logs that when the firewall pings the remote network it uses the wireguard IP but when the LAN device does it uses a local IP. So I think it's an issue with the LAN using the tunnel which is why I made the update.

[viragomann]

Accessing the remote site from a Wireguad client and from the local LAN are different things. The first one is a client to site design, the second is a site to site, however. And from what you wrote, you want to achieve a site to site.

In an S2S it's normal, that the remote site sees your local LAN IP, when accessing it.
But there are some requirements for a working s2s connection:
One I mentioned, your LAN subnet must be allowed in the remotes WG setting.
The remote site need to have routes for your LAN to point it to the WG server and further to your WG IP.
And the devices in the remote LAN need to allow access from your local LAN.
Nothing of these is set out of the box.

If the WG is designed as client to site, however, accessing from your LAN will only work with a masquerading rule.

[edickens]

Hello,

It's supposed to function like a client to site(we'll get the proper site to site up later). I see what you mean about needing the masquerade rule. I believe I got it setup in outbound NAT, but I seem to still have issues. Do I need to setup a gateway and route to go with it? Is there a difference between setting the translation address to the wireguard interface or the wireguard instance IP directly? I currently have it set to the instance IP.

Like I said before I can ping from the opnsense device but not the LAN I can also confirm the traffic is going out the wireguard interface. I did notice when I ping from the appliance it has the wireguard IP and when traffic comes from my LAN it doesn't which is why I thought it wasn't going down the tunnel.

I have setup the Local LAN subnet in allowed IP on the remote wireguard instance as well.

[viragomann]

Do I need to setup a gateway and route to go with it?

You need to add a static route for the remote LAN pointing to the remotes tunnel IP. But I assume, this is already done, since traffic goes into the tunnel.

Is there a difference between setting the translation address to the wireguard interface or the wireguard instance IP directly? I currently have it set to the instance IP.

I'd assume, that both are the same thing. But I don't use Wireguard, so not sure.
For other rules I use "interface address", which should also be well in this case.

[edickens]

I have new information. I didn't think this was pertinent but now I think it might be. I've been trying to get a VLAN tied to LAN interface to communicate. I got frustrated trying to get my machine to work started using tcpdump to see if the traffic was even making it (it is) but then for giggles I tried a ping on the "main" LAN hardwired computer and it just worked.

Now I know the connection is working and that LAN was what I was going to get to next so it saves that step. But I still don't know why my wireless VLAN isn't working.

[edickens]

Alright I am defeated but now know the answers. The reason my other network suddenly started working and the one I was working on didn't is because I had set my NAT outbound rules incorrectly. I had set it to my LAN rather than the VLAN I meant to. After correcting that mistake it's all working.

Thank you for your help it has been greatly appreciated.

[edickens]

I will also say for future people who may come across this in the future. I only have default gateways and routes setup, my firewall rules include the WAN rules from the site to site guide Wireguard interface rules and VLAN to remote network rules. I have a NAT outbound rule that sets VLAN outbound traffic to remote network to the IP set in Wireguard instance.

If you are having trouble, for troubleshooting purposes only open up the firewall rules. This allows you to troubleshoot just Wireguard. Make sure to reclose them.

Hopefully getting the proper site to site setup won't be quite as difficult, but I suspect will be more so.