Messages

I made it work finally. Basically the key thing is to have a route to LAN on the server which sits in the middle. I had to add LAN subnet to AllowedIPs there and also manually added the route (I guess wg-quick can do that automatically or via PostUp directive but I'm not using it).
And on laptop's side traffic to LAN should be routed through the tunnel as well.

I haven't tested performance yet and probably will need to play with MTU to make it work smoothly but the main thing is that it works and I don't care about port forwarding bug anymore :)

Thanks a lot for the idea with site-to-site VPN setup.

@Fright appreciate your input too. As I said above, site-to-site VPN sounds like a plan. But I'm a bit unclear regarding what changes I need to do in order to make it work as expected  ???

@Greelan thanks for the input.

I guess site-to-site setup might solve the problem. I remember how I tried to configure it with OpenVPN many years ago and failed. Since that I've been using port forwarding to access LAN resources over VPN (before with OpenVPN and now with Wireguard using Unifi USG but planning to move to Opnsense).

I've tried to play with AllowedIPs on both clients and "server" (I know that all peers are equal) but without any luck. Either I'm doing it wrong or something else is needed like additional NAT or firewall rules.

So here is my server config (has public WAN IP, deployed on VPS in AWS):

[Interface]
PrivateKey = <private-key>
ListenPort = 51820

[Peer]
# Opnsense
PublicKey = T48KrajQsS0hfY7e3A0df3zLi9ODX+naSH3STq7dpjw=
PresharedKey = <pre-shared-key>
AllowedIPs = 10.20.10.2/32

[Peer]
# Laptop
PublicKey = R534tXr0h1UapigeobiPt7h2yiNqce/LNj/QkkVq7Ws=
PresharedKey = <pre-shared-key>
AllowedIPs = 10.20.10.8/32

There're more peers there (other laptops, cell phones etc.) but I guess that doesn't matter for now.

Laptop configuration (it can be in any network, but I expect that as soon as I turn on Wireguard client, I get access to my home LAN resources behind Opnsense):

[Interface]
PrivateKey = <private-key>
Address = 10.20.10.8/24
DNS = 10.20.10.3

[Peer]
PublicKey = sqpFAEdKQ4kCoUvo00dK2ZIeAOWNvk0WAmTVFHJtBQk=
PresharedKey = <pre-shared-key>
AllowedIPs = 0.0.0.0/0
Endpoint = <server-endpoint:port>
PersistentKeepalive = 25

Opnsense configuration is attached (it acts as my home router with WAN connected to ISP and LAN to local switch).

And LAN subnet where web server is deployed is 192.168.40.0/24.

Based on the blog article above, I realize that this LAN subnets needs to be added to AllowedIPs list and I tried to do that but failed. So I'd appreciate if someone could point me to the changes I need to make here.

OK, seems like my problem is related to this https://github.com/opnsense/core/issues/4389.
And Wireguard VPN to LAN port forwarding is just totally broken at this moment  ???

I'm OK with just failover (when gateways have different tiers) for now. ISP offers me only 300 mb/s and one Wireguard instance fully covers that, so I can easily route all home traffic through the tunnel without a need for load balancing.

And forgot to mention that Nginx host actually can ping the laptop over VPN, though ping occasionally indicates redirect host:

PING 10.20.10.8 (10.20.10.8 ) 56(84) bytes of data.
64 bytes from 10.20.10.8: icmp_seq=1 ttl=62 time=87.8 ms
64 bytes from 10.20.10.8: icmp_seq=2 ttl=62 time=110 ms
64 bytes from 10.20.10.8: icmp_seq=3 ttl=62 time=33.1 ms
From 10.20.10.1: icmp_seq=4 Redirect Host(New nexthop: 10.20.10.8 )
64 bytes from 10.20.10.8: icmp_seq=4 ttl=62 time=52.4 ms
64 bytes from 10.20.10.8: icmp_seq=5 ttl=62 time=128 ms
64 bytes from 10.20.10.8: icmp_seq=6 ttl=62 time=21.8 ms
64 bytes from 10.20.10.8: icmp_seq=7 ttl=62 time=163 ms
64 bytes from 10.20.10.8: icmp_seq=8 ttl=62 time=41.8 ms
64 bytes from 10.20.10.8: icmp_seq=9 ttl=62 time=65.2 ms
From 10.20.10.1: icmp_seq=10 Redirect Host(New nexthop: 10.20.10.8 )
64 bytes from 10.20.10.8: icmp_seq=10 ttl=62 time=87.1 ms
64 bytes from 10.20.10.8: icmp_seq=11 ttl=62 time=110 ms

I'm running quite basic configuration where Opnsense is connected directly to my ISP and to LAN switch. Opnsense has VPN client running (wireguard) which is connected to the server deployed in the cloud (self-hosted, IP 10.20.10.1). The goal is to access some LAN resources behind Opnsense through VPN to LAN port forwarding.

Lab environment:
* Opnsense (VPN IP: 10.20.10.2)
* Laptop (VPN IP: 10.20.10.8 ) — connected to the same VPN server as Opnsense.
* Nginx in LAN is listening on 192.168.40.100:5001.

Opnsense firewall is configured in a way that 10.20.10.8:5001 redirects to 192.168.40.100:5001.
So, expected behavior is when laptop hits 10.20.10.8:5001 it being redirected to 192.168.40.100:5001. I guess this is a common setup for anyone who would like to access any LAN services over the VPN from external networks.

I'm running tcpdump on the laptop (VPN interface), Opnsense (VPN interface) and LAN server (on the interface where Nginx is listening).

I see that request from the laptop reaches Nginx, so apparently port forwarding works. But Nginx response never reaches the laptop. This is how traceroute looks from Nginx to the laptop:

traceroute to 10.20.10.8 (10.20.10.8 ), 30 hops max, 60 byte packets
1  192.168.40.1 (192.168.40.1)  0.202 ms  0.266 ms  0.162 ms
2  10.20.10.1 (10.20.10.1)  16.096 ms  16.075 ms  16.067 ms

I'm not sure if this is right that the first hop is 192.168.40.1, I'd expect that it would be 10.20.10.1. And running tcpdump on Opnsense I indeed see that 192.168.40.1 receives the response packet from Nginx but it never forwards it to the VPN server (10.20.10.1). Obviously that's the reason why the laptop doesn't get a response too.

Is that something that potentially can be configured using Opnsense (I mean VPN to LAN port forwarding)? What am I missing here?

I observe similar problem. Trying to load balance traffic between two VPN tunnels in a gateway group. As long as both tunnels have the same tier set, Internet connection becomes unstable and hardly usable. This disappears as soon as different tiers are defined for each tunnel in a gateway group (failover without load balancing).
Sticky sessions are enabled.