Messages

First some facts about my network(s) and my goal(s):

• LAN net: 10.0.0.0/24, dynamic /56 Prefix from my ISP
• Dual Stack setup
• WireGuard net: 10.0.1.0/24
• I want full LAN net access over WireGuard to my LAN net with IPv4 and IPv6
• All traffic from WireGuard clients should go over WireGuard connection
• To access the internet with active WG configuration, there's a specific gateway on my OPNsense the WG clients must use
• OPNsense version 24.7.11_2

WireGuard instance on my OPNsense:


Example of a peer configuration on my OPNsense:


Example of a WireGuard configuration of one of my clients:



WAN firewall rule to allow inbound WireGuard connections from WAN:


WireGuard firewall rules:



I tried this configuration, but all I could achieve so far is getting a connection between my OPNsense and the WG client, so that the WG client could access the internet from my OPNsense over the default gateway (but that's not what I want) and that only with IPv4. The LAN net isn't accessible at all.

Looks like I'm too blind to see why it isn't working. Would appreciate some help from more experienced people to tell me what I did wrong.

Thanks in advance.

I think firwall rules are ignored. Until I find a solution, I'm just gonna use my NAS in my LAN as exit node. This way everything works. But still, I'd prefer to use my OPNsense as endpoint.

Now that OPNsense also supports Tailscale, I've been working on it.

My goal is to use my smartphone on the go as if I were in my home network. To do this, I set up OPNsense as an exit node on my smartphone.

So far, that works to some extent, but I have a special case that unfortunately doesn't work yet:
Devices in my home network that communicate with the internet do so via a VPN gateway. To make this happen, I created a firewall rule for my LAN network that routes traffic accordingly through this gateway.

These are the rules on my LAN interface:


My idea was to achieve the same result for my smartphone by rebuilding the firewall rule in the same way on the Tailscale interface. However, there is a rule above it that allows network traffic into the LAN network via the default gateway. This allows me to access every device in my home network via my smartphone, and the traffic to the internet should be routed through the VPN gateway.

Here are the rules on my Tailscale interface:


Unfortunately, this didn't work in my test. When I check on my smartphone which public IP I have, it has the IP of the WAN interface of my OPNsense, and I don't understand why.

Can someone please tell me where the problem is here?

I think I found the culprit but I can't test right now because I have an appointment. I think it's DynDNS on my NAS. The IP behind its DynDNS domain changes to the public IP of my VPN server. This means clients from the internet try to access my NAS through the VPN tunnel which of course blocks the connection. Gotta do some testing later.

Nope, that sadly wasn't it. DynDNS gets the right public IP now but I still can't access my NAS from the internet.

The screenshot shows only the LAN rules. The interesting part would be the WAN rules.

There are no WAN rules.

I think I found the culprit but I can't test right now because I have an appointment. I think it's DynDNS on my NAS. The IP behind its DynDNS domain changes to the public IP of my VPN server. This means clients from the internet try to access my NAS through the VPN tunnel which of course blocks the connection. Gotta do some testing later.

The LAN rules shouldn't have any impact on traffic coming from WAN.

Well, looks like they do.

Do you have floating rules or interface group  rules?

You can see the floating rules in the screenshot at the top. They're just the three automatically created entries by the NAT port forwarding rules, as mentioned above. No group rules.

I uset NAT reflection on the port forward rules for the WAN and LAN interface. The LAN interface is now removed but still no luck accessing my hosted applications from the internet when my NAS is set to use the VPN tunnel gateway.  :-\

Maybe this helps a bit to clarify my setup. Here are my rules, the top three are the floating rules, generated by the NAT port forwards. What I do to make my NAS use the VPN tunnel gateway is to remove my NAS from the "Not_Mullvad_VPN" alias, so it's no longer in the alias, that is meant to use the default gateway.
Maybe you see something I'm too blind to see why it's not working.

I'm positive, yes. Tested it twice today. When I make my NAS use the VPN tunnel gateway for outbound traffic, I can't access my hosted services from the internet anymore.

Try outbound NAT on the LAN interface for anything coming from "the Internet" towards your NAS.

Thanks for the tip but that sadly didn't work.   :'(

So it the VPN your default gateway currently and are responses routed to it, even the requests come in on WAN?

The default gateway is my ISP's gateway but I made the NAS's outbound traffic use the VPN gateway with a firewall rule. And yes, request coming in on WAN, routed through the default gateway don't work.

Right, and I want that for connections intiated by my NAS.
Dumb example for this, just to make it more clear: Let's say I have a Firefox running in Docker on my NAS. Websites I visit with it should be routed through the VPN tunnel.

But here is what I want at the same time: When I'm not home and I want to synchronize mit Bitwarden vault with Vaultwarden, hosted in Docker on my NAS in my home LAN, the answer from my NAS should be routed through the default gateway (which is not the VPN tunnel gateway).

I need some help from someone who is experienced with firewall rules and has worked with the advanced features.

Context:
I have a NAS in my home LAN which hosts some docker containers like Vaultwarden and other stuff. Traffic from most of my devices (not my NAS) is routed through a WireGuard VPN tunnel, which is configured on my OPNsense. To achieve this I use firewall rules that use the VPN gateway for outgoing traffic. The reason why my NAS's outgoing traffic is not routed through the VPN tunnel is of course, because connection from the WAN to my NAS won't work anymore (I already tested that).

So I'm looking for a solution like this:

• Connections initiated by my NAS go through the VPN tunnel to the WAN.
• Answers to connection requests from the WAN to my NAS use the gateway, the initiated connection request came from.

I feel like the "reply-to" option in the advanced rule features could be something here, but I think all replies then will use the set gateway, even when the initiated connection from my NAS was routed through the VPN tunnel.

Is this even possible? If the answer is yes: Could you please explain to me how?

Others have reported this too. Could be something about the installed plugins. CrowdSec maybe?

While I can't tell you how well a fresh install + config backup restore works (because I simply upgraded), I can recommend you checking the OPNsense's subreddit. I usually check this place to get informed about problems other users had when upgrading or performing a fresh install. This post is the interesting one for you.
If I had to guess, a fresh install + config backup restore will work perfectly fine. Shout out to the OPNsense devs, they do an amazing job.

What's the "OPNsense's mapping".

The GUA my OPNsense gets after a reboot.

Static mappings are instant, except you use dynamic prefix magic prefix "::".

It would be easier to talk about the diff in the configuration...

Yes, it's a dynamic IPv6 I get from my ISP. I use a PPPoE connection for IPv4 and I get a dynamic IPv6 prefix via DHCPv6. LAN interface IPv6 configuration type is "Track Interface".
I'd love to give you more information but I don't know what else you need to know. Do you need screenshots?

Edit:
One thing I noticed: After a reboot as soon as it's possible to login on the WebUI I can see on the Dashboard that every service is running except for dhcpd6 which supports my guess in the OP. No, I don't start it manually. It takes a few seconds but after a refresh I see it finally running.

I'm talking about ISC DHCPv6 static mappings. Oh, and the OPNsense's mapping.