Messages

Any help would be appreciated!

I'm fuzzy on the Gateway if the route is via a local server's local IP hosting wg.

See the guide info below:

For the second thing, updating each site's routing tables, unfortunately you can't do via WireGuard config. You could configure each endpoint in both sites individually to route the traffic it generates destined for the other site through the WireGuard host in its own site — but the easiest thing to do is simply update the configuration of an existing gateway in each site to do that routing.

So for Site A, you want to update the gateway for the subnet that subsumes Site B's subnet (192.168.200.0/24), which usually would be the default gateway for Site A (like if Site A is a small office, it's probably the Internet router for the office). You want to add a route to this gateway to make it route Site B's subnet (192.168.200.0/24) via Host α (192.168.1.1) on the Site A (LAN) side of the gateway.

If this gateway is a Linux box, run the ip route command on the gateway to check what (IPv4) routes it currently is using (for IPv6, run ip -6 route). On Site A, the result might look something like this:

$ ip route
192.0.2.0/24 dev eth0 proto kernel scope link src 192.0.2.100
192.168.1.0/24 dev eth1 proto kernel scope link src 192.168.1.128
default via 192.0.2.1 dev eth0
The example above shows the gateway having an IP address of 192.0.2.100 on its eth0 network device, and 192.168.1.128 on its eth1 device. The eth1 device is connected to the Site A subnet, 192.168.1.0/24.

So run the following command on the gateway to (temporarily) add a route to Site B through Host α on the eth1 device:

ip route add 192.168.200.0/24 via 192.168.1.1 dev eth1
Replace the subnet for Site B (192.168.200.0/24) with the actual Site B subnet you're using, the IP address for Host α (192.168.1.1) with the actual Host α IP address you're using, and the network device name (eth1) with the actual name of the device through which the gateway is connected to Site A.

Note that adding a route this way just adds it temporarily, until the gateway is restarted or reconfigured — if you test out the WireGuard tunnel and everything works out, you'll want to make the route change permanent via whatever mechanism you regularly use to configure the gateway (like via networkd or netplan config files, or your own hand-built shell scripts, or some tool with a graphical user interface).

Similarly, check the routes used on Site B's default gateway with ip route, and then run a command on it like the following on it to add a route to Site A through Host β:

ip route add 192.168.1.0/24 via 192.168.200.2 dev eth1

Because I'm not in control of all the firewalls being used for this need.
This is a "routing in OPNsense" for wg question, not a call for help on how to set up wg on OPNsense.

Sorry if I put this question in the wrong subgroup.

[on]

"...with wg running on VMs behind OPNsense."

I need help setting the routes correctly in OPNsense when the wg peers are NAT'd behind OPNsense.
Did you look at the guide I provided the link to?
This is a "routing for 'service' on OPNsense" question...not how does wg work on OPNsense.

Hello everybody!
I'm trying to configure a wireguard site-to-site setup with wg running on VMs behind OPNsense.
I'm running into issues with how to route properly in OPNsense.  (Routing is a weak point in my knowledge)
I'm using the following guide:  https://www.procustodibus.com/blog/2020/12/wireguard-site-to-site-config/#configure-routing
Can someone explain to me how to route this correctly...like I'm a 6yo?

Thank you!

I posted this back on March 23rd in the 23.1 forum but since there were no replies, I thought I'd post it here.

This morning I started the day with 22.7.11 running on one of my proxmox servers.
We started noticing some webpages weren't accessible.  It progressively got worse so I start troubleshooting.  I quickly realized the OPNsense VM shell can ping external domain names, but any internal clients couldn't resolve external names.  I upgraded the VM to 23.1.4 in hopes it would solve the issue, but it did not.  I ended up restoring a VM backup to a known working state from 2.5 weeks ago and clients still couldn't resolve external names.
I then disabled Unbound and enabled Dnsmasq.  Clients started resolving correctly.
Why would 22.7.x and 23.1.x both have issues with internal clients resolving external names but as soon as I restored back to 22.7.x and then switched to Dnsmasq it started working?  Before moving to Dnsmasq I did check the logs and found nothing out of the ordinary for Unbound.
I see the current config as a workaround and not a fix.  Any ideas?
Thanks!!!

This morning I started the day with 22.7.11 running on one of my proxmox servers.
We started noticing some webpages weren't accessible.  It progressively got worse so I start troubleshooting.  I quickly realized the OPNsense VM shell can ping external domain names, but any internal clients couldn't resolve external names.  I upgraded the VM to 23.1.4 in hopes it would solve the issue, but it did not.  I ended up restoring a VM backup to a known working state from 2.5 weeks ago and clients still couldn't resolve external names.
I then disabled Unbound and enabled Dnsmasq.  Clients started resolving correctly.
Why would 22.7.x and 23.1.x both have issues with internal clients resolving external names but as soon as I restored back to 22.7.x and then switched to Dnsmasq it started working?  Before moving to Dnsmasq I did check the logs and found nothing out of the ordinary for Unbound.
I see the current config as a workaround and not a fix.  Any ideas?
Thanks!!!

This is a demo/lab setup.
I'll switch to Unbound on OPNsense to see what happens.
Thanks!

1. On the VM running OpenVPN, nslookup shows the pi-hole as the dns server...but wireshare shows no DNS traffic.
2. On a physical machine running OpenVPN, nslookup shows no name for the server but returns the proper remote DNS IP address.
     a. On the physical machine, OpenVPN local and remote traffic allowed = no wireshark traffic
     b. Also on the physical machine, OpenVPN all traffic tunneled = shows some MDNS traffic, but nothing returns.

This MDNS traffic seems to mainly be this:
2029   126.772892   10.222.77.6   224.0.0.251   MDNS   116   Standard query 0x0000 A wpad.local, "QM" question


This is really starting to wear on me.  Is there any hope or should I just use IP addresses???

UPDATE:
I've attached a wireshark screen capture of just the OpenVPN interface.  Maybe this will shed some light.

Wireshark shows the following when I run nslookup on the client:

OpenVPN local and VPN traffic allowed
395   40.241244   127.0.0.1   127.0.0.1   TCP   128   25340 → 52564 [PSH, ACK] Seq=352 Ack=1 Win=10233 Len=22
396   40.241276   127.0.0.1   127.0.0.1   TCP   84   52564 → 25340 [ACK] Seq=1 Ack=374 Win=1270 Len=0
nslookup returns pi-hole as server with local pi-hole IP address
No DNS info detected

OpenVPN VPN traffic only allowed
289   105.769055   127.0.0.1   127.0.0.1   TCP   128   25341 → 52578 [PSH, ACK] Seq=440 Ack=1 Win=10233 Len=22
290   105.769078   127.0.0.1   127.0.0.1   TCP   84   52578 → 25341 [ACK] Seq=1 Ack=462 Win=1270 Len=0
nslookup returns pi-hole as server with local pi-hole IP address
No DNS info detected


Viscosity local and VPN traffic allowed
47   31.517657   127.0.0.1   127.0.0.1   DNS   140   Standard query 0x0001 PTR 1.0.0.127.in-addr.arpa
48   31.517855   127.0.0.1   127.0.0.1   DNS   230   Standard query response 0x0001 PTR 1.0.0.127.in-addr.arpa PTR Viscosity
49   31.519132   127.0.0.1   127.0.0.1   DNS   150   Standard query 0x0002 PTR 21.x.x.192.in-addr.arpa
50   35.520116   127.0.0.1   127.0.0.1   DNS   84   Standard query 0xd161
nslookup returns Viscosity as the server with 127.0.0.1 IP address
DNS info detected but still no proper nslookup info returned on screen.

Do you have a fully populated reverse zone on your DNS server? Windows clients do a reverse lookup of the DNS server itself.

Try a packet capture on the client to see any failed lookups.

Bart...

I'm using Nethserver for DNS among other things.  Nethserver uses dnsmasq and the FQDN are in the /etc/hosts file.
Is there anything else in my dnsmasq setup I should look for?

I'm still working through wireshark.  When I know something I'll post it.

Thanks!

You may have just pushed me out of my knowledge zone.
I'll confirm reverse lookup, but I don't have the knowledge to do a packet capture.

It will be my Thursday before I can jump back on this.   Clients are calling!

Thanks!

[C:\Users\user1>nslookup "hostname"DNS request timed out. timeout was 2 seconds.Server: UnKnownAddress: 192.x.x.2DNS request timed out. timeout was 2 seconds.DNS request timed out. timeout was 2 seconds.*** Request to UnKnown timed-out]

I was testing on an esxi windows 10 vm.  I have switched over to a physical windows 10 machine and I see some different results.
1.  OpenVPN client seems to work a little better and tries to resolve to the remote DNS server.
2.  An nslookup now shows the  following:
C:\Users\user1>nslookup "hostname"
DNS request timed out.
    timeout was 2 seconds.
Server:  UnKnown
Address:  192.x.x.2

DNS request timed out.
    timeout was 2 seconds.
DNS request timed out.
    timeout was 2 seconds.
*** Request to UnKnown timed-out

FYI...
3.  direct firewall pass rules tested with the tunnel IP address did not change any results.
4.  DNS is not provided by OPNsense, but a Nethserver instance. (if this makes a difference)

Thanks!

@bartjsmit the DHCP seems to be working properly.  The config seems to populate correctly.  It's just not communicating correctly.
UPDATE:  Pushing the DHCP made the DHCP IP show up twice in the list and did not fix the issue.

@hutiucip I have attached an image.  Are you saying I need to add a rule that is more specific than this?
UPDATE:  I added a pass rule on the OpenVPN to allow all from the tunnel IP network.  This didn't help.

I'm using the community OpenVPN client.
tuXten has the same symptoms as the community client.

I seemed to get further with Viscocity...ipconfig /all would show their adapter first in the list and the remote DNS would show up before the local.  With or without directing all traffic through the tunnel, the nslookup would not reply correctly, but it was at lease showing the IP address of the remote DNS.  The "server" would show up as unknown.