Messages

1

Virtual private networks / Configure routes for access to remote site over client-to-site WireGuard

« on: June 26, 2024, 02:57:45 pm »

Hi all,

I have a setup with OpnSense at one location 'home' - it has a static WAN IP and runs a WireGuard server. I have a second location 'remote' on an EdgeRouter X. I have set that up with a WireGuard client config that connects to home. That site has firewall rules and routes configured to connect to resources at home from the LAN on remote.

I also setup a WireGuard server on the EdgeRouter for remote access / support if I needed - but that site is about to go behind CG NAT and I won't be able to connect to it anymore.

I am trying to workout what gateway and routes I need to setup on the OpnSense device to permit access from the 'Home' LAN to the resources in the 'Remote' LAN.

ie, load the web interface on 192.168.8.46

When I am on the OpnSense router I can ping the WG client IP 172.16.16.4 - but I can't ping it from any device on the LAN.

(IPs in the image are all made up, but reflect the environment, ie the LAN / WG subnets are all different.

Any advice?



Thanks

2

23.7 Legacy Series / Re: Near constant PTR lookups in DNS logs

« on: September 29, 2023, 05:08:44 am »

Thanks so much for the reply!

I had looked at a packet capture, but the source was always 127.0.0.1 - so something on the device was creating the requests.

But, it was that config in AdGuard!

Not my first or only Ad Guard service running, so not sure why those options were on / enabled by default.

But fixed now

Thanks again.

3

23.7 Legacy Series / Re: Near constant PTR lookups in DNS logs

« on: September 24, 2023, 11:41:08 am »

Did the update to 23.7.4 and then spent some time stopping a lot of services one at a time on the router to see if the lookups stopped, but they continue.

Spent some time going over logs and the only thing I could find these log entries:

configd/latest.log:<13>1 2023-09-24T18:57:10+10:00 gateway.home.256.network configd.py 242 - [meta sequenceId="157"] [1e7976fe-725b-4acc-afb5-c0e6d58acb83] request arp table
configd/latest.log:<13>1 2023-09-24T18:57:22+10:00 gateway.home.256.network configd.py 242 - [meta sequenceId="158"] [e75cbea3-3b67-43c9-8a52-24b5cc0583e8] request arp table
configd/latest.log:<13>1 2023-09-24T18:57:34+10:00 gateway.home.256.network configd.py 242 - [meta sequenceId="159"] [3400cc11-905c-4799-8e3b-cb0694395fda] request arp table
configd/latest.log:<13>1 2023-09-24T18:57:46+10:00 gateway.home.256.network configd.py 242 - [meta sequenceId="160"] [99345e14-81f6-4ab7-a1da-bc6f357e37b3] request arp table
configd/latest.log:<13>1 2023-09-24T18:57:58+10:00 gateway.home.256.network configd.py 242 - [meta sequenceId="161"] [10054ff0-ed8c-427b-aa3c-a12950a196ff] request arp table

But I still can't workout what is creating the requests.

Any ideas?

Thanks.

4

23.7 Legacy Series / Near constant PTR lookups in DNS logs

« on: September 15, 2023, 02:09:04 am »

On my current install of OpnSense I have near constant lookups for PTR records for all my internal IPs (ones reserved in DHCP, and any standard leases. There are blocks of lookups only a few seconds apart - example attached.

Screenshot of lookups https://i.imgur.com/NlNkDR3.png

As an example of how many requests are being made:
https://i.imgur.com/vXTvlvi.png
https://i.imgur.com/aBtM6eN.png

Much searching lead me to a possible patch Unbound.inc for how it was handling aliases for 23.7 -> https://github.com/opnsense/core/pull/5925

However I think unbound.inc has been patched in my deployment already.

When I first installed the system it was using Unbound for DNS, but I moved to AdGuard. Moving back to Unbound for DNS didn't change anything. Unbound is not currently running as a service.

I was reading somewhere that it was a reporting component creating all the requests, but I have turned off most of the reporting I could find that I thought could be generating the request.


Report config:
https://i.imgur.com/be36sP4.png

Collected reports:
 ipsec-packets
 ipsec-traffic
 lan-packets
 lan-traffic
 opt1-packets
 opt1-traffic
 opt2-packets
 opt2-traffic
 opt3-packets
 opt3-traffic
 opt4-packets
 opt4-traffic
 system-cputemp
 system-mbuf
 system-memory
 system-processor
 system-states
 wan-packets
 wan-traffic


Installation:
Version: 23.7.3   
Architecture: amd64   
Commit: 273c5bf46

Any ideas?

Thanks.

5

23.7 Legacy Series / Re: WG client related DNS resolution issue when DNS is other than unbound

« on: September 14, 2023, 07:10:50 am »

I think I have resolved my issue - the upstream connection from my Ad Guard wasn't working - resolved that and I think it is all happy now - check your upstream resolver on your UnBound DNS?

6

23.7 Legacy Series / Re: WG client related DNS resolution issue when DNS is other than unbound

« on: September 14, 2023, 04:34:00 am »

I've just started having issues with DNS over WireGuard today. I seem to be able to resolve internal Hostnames / IPs, but resolution for public addresses fail.

I am using AD Guard instead of Unbound DNS - running on OpnSense

I can resolve public DNS using a public server (1.1.1.1)

I am experiencing similar issues on multiple devices (MacBook, iPhone) on multiple networks (local wifi, 4G networks), and to multiple WireGuard servers (home - OpnSense, and a VM on AWS).

It seems like there might have been an issue with an update to the WireGuard client which I think updated last night on my phone, and maybe yesterday on my Mac?

Example attempts at DNS resolution from my MacBook all while connected to a WireGuard VPN running on OpnSense at home.

EDIT: WireGuard client seems to be 6 months old, and hasn't been updated, which just confuses me :-)

Code: [Select]

alloneword@TimMBP ~ % nslookup google.com
;; connection timed out; no servers could be reached

alloneword@TimMBP ~ % nslookup google.com 192.168.4.1
;; connection timed out; no servers could be reached

alloneword@TimMBP ~ % nslookup google.com 1.1.1.1   
Server: 1.1.1.1
Address: 1.1.1.1#53

Non-authoritative answer:
Name: google.com
Address: 172.217.24.46

alloneword@TimMBP ~ % nslookup google.com 192.168.1.254
;; connection timed out; no servers could be reached

alloneword@TimMBP ~ % nslookup gateway.stuff
Server: 192.168.4.1
Address: 192.168.4.1#53

Non-authoritative answer:
Name: gateway.stuff
Address: 192.168.1.254