Site-to-Site WireGuard passing traffic only for certain IP range

[mimugmail]

yes, please call it different than wireguard. no ip, enable lock, then restart your wireguard config and you are good.

[szty0pa]

Thank you. Did that and will test it from home (the remote site) in the evening.

[szty0pa]

Hi Michael,

Sadly it did not work. I can ping anything on the other side of the tunnel (even the firewall itself), i can log into the server behind the firewall, but not to the firewall itself (and DNS does not work either).

Just to make sure i've got everything right and for future reference:
 - Wireguard network is setup as 10.1.1.0/24, site A network 10.10.0.0/16, site B network 10.20.0.0/16 routed through Wireguard
 - 'vpn' interface assigned to wg0 without any configuration, enabled and locked
 - added firewall rule to 'vpn' and Wireguard interfaces to allow all incoming traffic (for the time being until it works) - do we need both?
 - added outbound NAT rule to map everything to the interface address on the Wireguard interface (as i am connecting/testing from a 192.168.1.0/24 network)
 - (optional: added UDP traffic on default port 51820 to the traffic shaper to prioritize VPN traffic)
 - added the 'vpn' interface to the secure shell and web GUI 'listen interfaces' lists
 - added the 'vpn' interface to the 'network interface' list in Unbound, set up forward-zone in custom options and added 10.1.1.0/24 and 10.x.0.0/16 (the network on the other side of the tunnel) to the access list
 - restarted Unbound
 - restarted Wireguard

What am i missing?
(I even tried assigning 10.1.1.1/24 to the 'vpn' interface, restarting Wireguard, and logging in via ssh to a host on site B (from site A; this succeeded) to try to log back in to the firewall at site A through ssh from that host at site B (this timed out).)

Thanks for your help in advance!

[mimugmail]

What happens when you connect to the LAN IP of the Firewall via the tunnel?

[szty0pa]

It times out. (Same behaviour as when i try to access it from an interface not added to the access list.)

[mimugmail]

Screenshot of tunnel addresses on the client please

[szty0pa]

There you go.

edit: [images removed]

[mimugmail]

These screenshots are from the OPN as your central server or your client?

[szty0pa]

These are the config screenshots from one of the two sites. They have symmetrical configurations, so there is no server/client relationship, it's more like two identical peers connecting/sharing the networks behind them.
The only difference is that this (shown site) has the tunnel IP of 10.1.1.1 and the network behind is 10.10.0.0/16, while the other site's tunnel address is 10.1.1.2 and is on the network 10.20.0.0/16. (There is an extra entry - 10.1.1.10 for mobile access, but that does not work yet for some reason... probably to do with android. So is irrelevant for now.)

[szty0pa]

Remote web access now works after the upgrade, thanks!
Still playing around with the unbound forward zones (dns resolution works according to dig, but not automatically through unbound yet).

edit: THE SOLUTION

For reference and if anyone's interested here's how to enable recursive domain name resolution between two local networks: insert the below lines to your unbound config:

val-permissive-mode: yes
private-domain:  <your remote domain>
domain-insecure: <your remote domain>

Most of these lines are required if you (like me) are not running unbound in a way that it provides authorative dnssec-validated responses. That's still up to figure out. Hope this helps anyone anyway.

[lshantz]

Greetings....

It is fantastic you went to the trouble to detail this. The instructions on the opnsense doc site are very inadequate. Hopefully they will allow somebody to flesh it out more completely soon.

I was going to ask if you would consider updating the docs, since it is no longer dev, but part of the latest update.

I must be doing something wrong, because I'm not seeing an Wireguard wg0 to add. Still fooling around to figure out why not.
later: I figured it out. Wireguard services were not starting. The only way to get the service to fire up, was to disable the endpoint. I suspect it might be the chicken or the egg thing. No rules were set up in the firewall, so I'm thinking the endpoint would abend the service. But once the service is running, then I can assign wg0. Maybe someone else will be helped by this.

EDIT: Later... we have gotten the tunnel established.... But we must be missing routing or rules because we can't go any farther. This is harder to setup than openvpn and it shouldn't be. There are several sites all giving different instructions.. so who to follow. gah!