OPNsense Forum
Archive => 20.1 Legacy Series => Topic started by: alexktz on July 20, 2020, 05:54:45 pm
-
I recently switched from pf to opn and am very glad I did. I was hoping for some assistance with configuring a remote firewall I loaded with opn this weekend.
The wireguard tunnel is configured just fine. In fact, the only way I can administer the remote firewall is using the WG tunnel, so it works. The snag I'm running into is that no DNS is working. Here are some key IPs:
* Firewall - 192.168.75.254 (Remote LAN IP), 10.42.13.1 (WG tunnel IP)
The firewall serves as it's own DNS server using Unbound. I can verify this with dig on the firewall itself via SSH. Most guides seem to rely on external Pihole or other servers, I'm wondering if I'm maybe missing a rule to allow DNS to traverse from the wg0 net? I can ping 192.168.75.254 from the client. Running low on ideas how to troubleshoot it.
[user@OPNsense ~]$ dig google.com
; <<>> DiG 9.16.4 <<>> google.com
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 52031
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;google.com. IN A
;; ANSWER SECTION:
google.com. 191 IN A 216.58.198.174
;; Query time: 0 msec
;; SERVER: 127.0.0.1#53(127.0.0.1)
;; WHEN: Mon Jul 20 15:42:15 GMT 2020
;; MSG SIZE rcvd: 55
As you can see, DNS in being fulfilled by 127.0.0.1. I experimented with putting the LAN IP in System -> Settings -> General but it behaved the same.
The issue I have is that when connected to the firewall via the WG tunnel dig shows 'WARNING: recursion requested but not available'. Here's the full output (run from my laptop connected via the tunnel)
alex@mooncake ~ % dig google.com
; <<>> DiG 9.10.6 <<>> google.com
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: REFUSED, id: 8748
;; flags: qr rd ad; QUERY: 0, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 0
;; WARNING: recursion requested but not available
;; Query time: 122 msec
;; SERVER: 192.168.75.254#53(192.168.75.254)
;; WHEN: Mon Jul 20 11:44:31 EDT 2020
;; MSG SIZE rcvd: 12
The DNS server 192.168.75.254 is being provided by the WG tunnel to the client. Putting 1.1.1.1 in makes no difference either. LAN hosts are reachable via IP but not via DNS.
This makes me think I’ve probably screwed up rules somewhere, here’s screenshots of the whole thing (wish there was a better way to share configs than screenshots!).
screenshots - https://imgur.com/a/SdyDUIS
Any help would be greatly appreciated. I hope I've missed a simple setting somewhere obvious. Thanks in advance.
-
I thought I'd gotten somewhere when I found [this bug](https://github.com/opnsense/core/issues/4142). I manually added my client (mooncake) to the Unbound ACL and now dig is not suffering from the recursive denial previously. DNS works as you'd expect with dig but no useful traffic passes.
I've monitored with tcpdump and see the traffic on port 53 passing OK. Monitoring port 443 tons and tons scrolls by when I attempt to load a webpage whilst connected but it never loads.
alex@mooncake ~ % dig google.com
; <<>> DiG 9.10.6 <<>> google.com
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 23851
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;google.com. IN A
;; ANSWER SECTION:
google.com. 295 IN A 216.58.210.46
;; Query time: 115 msec
;; SERVER: 192.168.75.254#53(192.168.75.254)
;; WHEN: Mon Jul 20 22:41:42 EDT 2020
;; MSG SIZE rcvd: 55
alex@mooncake ~ % ping google.com
PING google.com (216.58.210.46): 56 data bytes
Request timeout for icmp_seq 0
Once I get this working I will contribute documentation to the project but I'm pretty close to throwing in the towel at this point.
I'm positive that every setting and firewall rule matches the collection of guides I've followed. Can anyone help please?
-
I'd guess it's something MTU/MSS related
-
I'd guess it's something MTU/MSS related
Based on?
-
I'd guess it's something MTU/MSS related
Based on?
Experience :)
Try to assign WG interface and set mss to 1300
-
Like this?
Didn't seem to make any difference.
-
Ah, you need to add your tunnel network to outbound nat
-
I think already did?
(https://i.imgur.com/6xj1xNh.jpg)
-
WOW. Ok, I want a refund. Literally about 12-16hrs of my life because I'd set the tunnel address in 'local' as a /32 and not a /24. I hope this helps any future idiots :o
Works now. :massive-facepalm: