Topics

1

Virtual private networks / Is there a way to programatically change Wireguard settings?

« on: March 28, 2021, 11:18:48 am »

Mullvad has a Bash script that appears to query their API to (1) get a list of their Wireguard server's public keys and locations, (2) generate your private key, (3) query their API to register your public key with Mullvad under your account, (4) save the API's response with the local interface address, and (5) write a Wireguard configuration file based on all of this info.  The script is here:  https://mullvad.net/media/files/mullvad-wg.sh

I am wondering if in OPNsense, one can change the Wireguard settings programmatically, and if so, how?  Is there an API to change the settings you see in the GUI?

I am interested in creating a cron job that can periodically (1) rotate the Mullvad endpoint, and (2) change the private key and other related settings.  Mullvad's own script seems like a helpful starting point.  If there is an API in OPNsense to change these settings, then this seems very doable.  Any insights would be greatly appreciated.

Also, does OPNsense have bash installed by default?

2

21.1 Legacy Series / [SOLVED] Unbound Fails to Resolve Selected Domains

« on: March 05, 2021, 08:46:40 am »

I have a very weird DNS resolution problem that I cannot figure out.  I'm running OPNsense 20.7.8_4.  I'm using unbound in resolver mode with DNSSEC turned on and unbound traffic sent out via Mullvad OpenVPN (UDP) tunnel. 

The setup generally works great, but for some reason, unbound fails to resolve certain domains.  For example, it will not resolve "workplace.schwab.com."  There are likely other domains, but I don't have a list.  What I found is that unbound will resolve "workplace.schwab.com" if I either:

1) turn off DNSSEC (and continue to send unbound traffic via VPN); OR

2) send unbound traffic out via WAN (in this case, I do NOT have to turn off DNSSEC).

If I do not do either of the above, unbound does not resolve "workplace.schwab.com".  If I go to Interfaces --> Diagnostics --> DNS Lookup and put in "workplace.schwab.com," it would take about 10 seconds to run, and return the following:

Code: [Select]

Response
Type Address
CNAME workplace.gslb.schwab.com.
A 162.93.221.50

Resolution time per server
Server Query time
127.0.0.1 No response
1.1.1.1 45 msec
1.0.0.1 8 msec
As you can see above, in forward mode (to 1.1.1.1 or 1.0.0.1), DNS resolution works fine.  But unbound at 127.0.0.1 gets "No response."

If I SSH into OPNsense and run dig at the shell, nothing seems obviously wrong EXCEPT the dig takes like 2.5 minute to complete (it pauses for a super long time between the first block of output for the root-servers and the second block of output, then the remaining blocks of output follow very quickly).  Here is the output.

Code: [Select]

root@OPNsense:~ # dig @127.0.0.1 workplace.schwab.com +trace

; <<>> DiG 9.16.10 <<>> @127.0.0.1 workplace.schwab.com +trace
; (1 server found)
;; global options: +cmd
.                       80398   IN      NS      m.root-servers.net.
.                       80398   IN      NS      a.root-servers.net.
.                       80398   IN      NS      b.root-servers.net.
.                       80398   IN      NS      c.root-servers.net.
.                       80398   IN      NS      d.root-servers.net.
.                       80398   IN      NS      e.root-servers.net.
.                       80398   IN      NS      f.root-servers.net.
.                       80398   IN      NS      g.root-servers.net.
.                       80398   IN      NS      h.root-servers.net.
.                       80398   IN      NS      i.root-servers.net.
.                       80398   IN      NS      j.root-servers.net.
.                       80398   IN      NS      k.root-servers.net.
.                       80398   IN      NS      l.root-servers.net.
.                       80398   IN      RRSIG   NS 8 0 518400 20210318050000 20210305040000 42351 . RGrSTUNk4Ad41ITau7wzwMrm6Uk/ReeJlR/1cul8D1bs7qdYZOeICUvX CU+j9KipCbh0VUKvbcVWXFlpWoy9k/4ay0u1ZB5BbooERfyfGVyTe4ru pXrXymKeFLetZFhUr2KoO6ITyigRPPNvJFkRhwUn6nHqgCiHEvdG2cZW FmmvFpZ+0ejIB1h7lJYg+iaG8be2tI3aXp3CF/u8Cerjii5DddESAZrL bR9K6SeeQB9GxabnQJMvFY2FXsHBps9BQkx6D1vc5Vpn8E7R4e3uIcte Rt0c7fwvOyZE1lwHsvhxIaXugLJdlSX0bWT5XwGtGFm3xo6OHuL2cqXJ 9HbxVQ==
;; Received 525 bytes from 127.0.0.1#53(127.0.0.1) in 0 ms

com.                    172800  IN      NS      l.gtld-servers.net.
com.                    172800  IN      NS      b.gtld-servers.net.
com.                    172800  IN      NS      c.gtld-servers.net.
com.                    172800  IN      NS      d.gtld-servers.net.
com.                    172800  IN      NS      e.gtld-servers.net.
com.                    172800  IN      NS      f.gtld-servers.net.
com.                    172800  IN      NS      g.gtld-servers.net.
com.                    172800  IN      NS      a.gtld-servers.net.
com.                    172800  IN      NS      h.gtld-servers.net.
com.                    172800  IN      NS      i.gtld-servers.net.
com.                    172800  IN      NS      j.gtld-servers.net.
com.                    172800  IN      NS      k.gtld-servers.net.
com.                    172800  IN      NS      m.gtld-servers.net.
com.                    86400   IN      DS      30909 8 2 E2D3C916F6DEEAC73294E8268FB5885044A833FC5459588F4A9184CF C41A5766
com.                    86400   IN      RRSIG   DS 8 1 86400 20210318050000 20210305040000 42351 . bVi/an3ya9VuX/O+2R5wTHP5+Ea7jmmQD+ZVs6rbmTpExiGl8Hsc8P+5 HSIbOcN9qcv/wnXoVwm8zLQojXWxJO4o4rkfAWI2fQ4ZvgEzZF5rxbmz DhOrXOexP7Yick8UqQpX8KADBrU6cH+jv1sYcc+pcDX0GzIq/LQV3bSa crTjtxBiqhYT8LD3d7bQ/kDbo6jyXMQTe77j2qFohW2+X3KBTpfFK6BZ iIrslY0OUYSCMqasCk9v5wSkM3qE0ebJlo71zcJVeGVaLEAEupS/HEzb ne+KSBIOMHJ3zSmZaFMXCZPSYmBAF2poNSh+L13Xpkf4Ib7w12PtWPUz BplviQ==
;; Received 1180 bytes from 192.5.5.241#53(f.root-servers.net) in 7 ms

schwab.com.             172800  IN      NS      ns1.schwab.com.
schwab.com.             172800  IN      NS      ns2.schwab.com.
schwab.com.             172800  IN      NS      ns3.schwab.com.
schwab.com.             172800  IN      NS      ns4.schwab.com.
schwab.com.             172800  IN      NS      a9-65.akam.net.
schwab.com.             172800  IN      NS      a8-64.akam.net.
schwab.com.             86400   IN      DS      3829 8 2 8B39D6D8CE4FA5D55DEB38CF05BB81E0CC087FA978AB9E0721411513 86CF2EA2
schwab.com.             86400   IN      RRSIG   DS 8 2 86400 20210309054915 20210302043915 58540 com. WCclyXLsxq4uaQpBB5WFJZvYbVNCra/EeN/AaBE+xVT0e+W9P0rJnWOM 1MdQ+FFdQDQndy9HQantJh7pOYsrroIrBDC84/MvvihnAzl0cSzUv8/1 zH95Rn0TGmyP1iGtUoBR9LTspXOy6vd6bsi3x8/J/KjzHco31YeBig1j nUSvSOG+w0gOx5XWq+1jkfh8rtIVTb8gDfDRc/muamDnNQ==
;; Received 476 bytes from 192.54.112.30#53(h.gtld-servers.net) in 22 ms

workplace.schwab.com.   300     IN      CNAME   workplace.gslb.schwab.com.
workplace.schwab.com.   300     IN      RRSIG   CNAME 8 3 300 20210313093720 20210211084427 43563 schwab.com. HMRYlzV44nhXrDntld7SwDAbk/zihLTrIwF+O6TnjdBjzwyAmYmT1BJA 9cAT7JAtQ8jKrkQDXvfrVdWZWiN/Pgrd1sjpprnasNaggYG/lg9hsfWU PawjDfTLfXs0jC/6PVHNcmJS1JoplkB8ccdzFMbFDw6qpxhx5ISP3MeX yl9yKrl7YJH69ufLv503ZU0tKKZ6oHJg60D07U9uxSuu6LZ6aDbYT0IA SHCEgVWq25uKBTS8eTekYalS0clyCYH9oeJ9JRN0GL84AoAlsZqOUeEj rde0yCzPk/aTCTZat8PgCP0Uz4gP/ooz6htu7TdCL7hDhqlRjbdowgIW Lq6CFg==
gslb.schwab.com.        900     IN      NS      gslb-anycast.schwab.com.
gslb.schwab.com.        86400   IN      DS      28456 8 2 D62CE9A0008171EE1F9DAC7A50AC167ADFCCF12A85C0314083F9CB86 8AC8C52F
gslb.schwab.com.        86400   IN      RRSIG   DS 8 3 86400 20210313094830 20210211090458 43563 schwab.com. ZaD1MLn/fOWaXgwZ6pyP2eKF5aG4t6fwjnRau/YF6zjigvfGHU+sNa26 qyzcFu2dnEUZsmnie2WDN4w7IhnkbzRUnzPN2Dkegj7gVvJ23UbkDOxP sQIxLWkog5okaUK9fv03Rh9pNk8pTEVUoSn/nnuPXrU57eJwscl2BJCc 6dzDuruTNE+wtmHe97tv3HZupWhyy4B5MpAKh6awWRBShpLmIE2NK0cR Hkwfo+Vb1cE2yfH6XTDQA/QeV1mBw32uvPQBT9Tp1ZGF6THjqZWyfaCV 1hsSN+KWavOgAjWxIt0OqJrfGewaQCQJDn5n0MrXQxB3ndoSxk/8/vYk wALTcw==
;; Received 1063 bytes from 162.93.253.171#53(ns3.schwab.com) in 43 ms

And if I dig "workplace.gslb.schwab.com" I get the correct IP address (162.93.221.50).  Again, the dig takes 2.5 minutes to complete, but the pause is only between the first block of output and the second block of output.  Here is the output.

Code: [Select]

root@OPNsense:~ # dig @127.0.0.1 workplace.gslb.schwab.com +trace

; <<>> DiG 9.16.10 <<>> @127.0.0.1 workplace.gslb.schwab.com +trace
; (1 server found)
;; global options: +cmd
.                       80069   IN      NS      i.root-servers.net.
.                       80069   IN      NS      j.root-servers.net.
.                       80069   IN      NS      k.root-servers.net.
.                       80069   IN      NS      l.root-servers.net.
.                       80069   IN      NS      m.root-servers.net.
.                       80069   IN      NS      a.root-servers.net.
.                       80069   IN      NS      b.root-servers.net.
.                       80069   IN      NS      c.root-servers.net.
.                       80069   IN      NS      d.root-servers.net.
.                       80069   IN      NS      e.root-servers.net.
.                       80069   IN      NS      f.root-servers.net.
.                       80069   IN      NS      g.root-servers.net.
.                       80069   IN      NS      h.root-servers.net.
.                       80069   IN      RRSIG   NS 8 0 518400 20210318050000 20210305040000 42351 . RGrSTUNk4Ad41ITau7wzwMrm6Uk/ReeJlR/1cul8D1bs7qdYZOeICUvX CU+j9KipCbh0VUKvbcVWXFlpWoy9k/4ay0u1ZB5BbooERfyfGVyTe4ru pXrXymKeFLetZFhUr2KoO6ITyigRPPNvJFkRhwUn6nHqgCiHEvdG2cZW FmmvFpZ+0ejIB1h7lJYg+iaG8be2tI3aXp3CF/u8Cerjii5DddESAZrL bR9K6SeeQB9GxabnQJMvFY2FXsHBps9BQkx6D1vc5Vpn8E7R4e3uIcte Rt0c7fwvOyZE1lwHsvhxIaXugLJdlSX0bWT5XwGtGFm3xo6OHuL2cqXJ 9HbxVQ==
;; Received 525 bytes from 127.0.0.1#53(127.0.0.1) in 0 ms

com.                    172800  IN      NS      a.gtld-servers.net.
com.                    172800  IN      NS      b.gtld-servers.net.
com.                    172800  IN      NS      c.gtld-servers.net.
com.                    172800  IN      NS      d.gtld-servers.net.
com.                    172800  IN      NS      e.gtld-servers.net.
com.                    172800  IN      NS      f.gtld-servers.net.
com.                    172800  IN      NS      g.gtld-servers.net.
com.                    172800  IN      NS      h.gtld-servers.net.
com.                    172800  IN      NS      i.gtld-servers.net.
com.                    172800  IN      NS      j.gtld-servers.net.
com.                    172800  IN      NS      k.gtld-servers.net.
com.                    172800  IN      NS      l.gtld-servers.net.
com.                    172800  IN      NS      m.gtld-servers.net.
com.                    86400   IN      DS      30909 8 2 E2D3C916F6DEEAC73294E8268FB5885044A833FC5459588F4A9184CF C41A5766
com.                    86400   IN      RRSIG   DS 8 1 86400 20210318050000 20210305040000 42351 . bVi/an3ya9VuX/O+2R5wTHP5+Ea7jmmQD+ZVs6rbmTpExiGl8Hsc8P+5 HSIbOcN9qcv/wnXoVwm8zLQojXWxJO4o4rkfAWI2fQ4ZvgEzZF5rxbmz DhOrXOexP7Yick8UqQpX8KADBrU6cH+jv1sYcc+pcDX0GzIq/LQV3bSa crTjtxBiqhYT8LD3d7bQ/kDbo6jyXMQTe77j2qFohW2+X3KBTpfFK6BZ iIrslY0OUYSCMqasCk9v5wSkM3qE0ebJlo71zcJVeGVaLEAEupS/HEzb ne+KSBIOMHJ3zSmZaFMXCZPSYmBAF2poNSh+L13Xpkf4Ib7w12PtWPUz BplviQ==
;; Received 1185 bytes from 198.97.190.53#53(h.root-servers.net) in 23 ms

schwab.com.             172800  IN      NS      ns1.schwab.com.
schwab.com.             172800  IN      NS      ns2.schwab.com.
schwab.com.             172800  IN      NS      ns3.schwab.com.
schwab.com.             172800  IN      NS      ns4.schwab.com.
schwab.com.             172800  IN      NS      a9-65.akam.net.
schwab.com.             172800  IN      NS      a8-64.akam.net.
schwab.com.             86400   IN      DS      3829 8 2 8B39D6D8CE4FA5D55DEB38CF05BB81E0CC087FA978AB9E0721411513 86CF2EA2
schwab.com.             86400   IN      RRSIG   DS 8 2 86400 20210309054915 20210302043915 58540 com. WCclyXLsxq4uaQpBB5WFJZvYbVNCra/EeN/AaBE+xVT0e+W9P0rJnWOM 1MdQ+FFdQDQndy9HQantJh7pOYsrroIrBDC84/MvvihnAzl0cSzUv8/1 zH95Rn0TGmyP1iGtUoBR9LTspXOy6vd6bsi3x8/J/KjzHco31YeBig1j nUSvSOG+w0gOx5XWq+1jkfh8rtIVTb8gDfDRc/muamDnNQ==
;; Received 481 bytes from 192.43.172.30#53(i.gtld-servers.net) in 24 ms

gslb.schwab.com.        900     IN      NS      gslb-anycast.schwab.com.
gslb.schwab.com.        86400   IN      DS      28456 8 2 D62CE9A0008171EE1F9DAC7A50AC167ADFCCF12A85C0314083F9CB86 8AC8C52F
gslb.schwab.com.        86400   IN      RRSIG   DS 8 3 86400 20210313094830 20210211090458 43563 schwab.com. ZaD1MLn/fOWaXgwZ6pyP2eKF5aG4t6fwjnRau/YF6zjigvfGHU+sNa26 qyzcFu2dnEUZsmnie2WDN4w7IhnkbzRUnzPN2Dkegj7gVvJ23UbkDOxP sQIxLWkog5okaUK9fv03Rh9pNk8pTEVUoSn/nnuPXrU57eJwscl2BJCc 6dzDuruTNE+wtmHe97tv3HZupWhyy4B5MpAKh6awWRBShpLmIE2NK0cR Hkwfo+Vb1cE2yfH6XTDQA/QeV1mBw32uvPQBT9Tp1ZGF6THjqZWyfaCV 1hsSN+KWavOgAjWxIt0OqJrfGewaQCQJDn5n0MrXQxB3ndoSxk/8/vYk wALTcw==
;; Received 741 bytes from 162.93.195.171#53(ns4.schwab.com) in 44 ms

workplace.gslb.schwab.com. 20   IN      A       162.93.221.50
workplace.gslb.schwab.com. 20   IN      RRSIG   A 8 4 20 20210308200738 20210301200738 46146 gslb.schwab.com. rjkuOJx+2tBnwv3Hm3CJEhHSxx4+NMzFuw1iNnPUTxewzx8RaqKdqX3K vIhGDCGoVIWJLeL/QiKvXnpulAIg1y3Aha9DCnsPNPJY4kJ61D3+PkeP Ygx3bEQETt+EFd+CIDjhgYlmZLkt5pkSMhONaPK4cXUBYBbPsoYW5b/u TZtzGcVaqmoRGbJgiildwfeqgykH+dER/tZ2E3/yIxvZnVnorcQFYPw9 t7F88iSOnSLg3253CHxu6iU8d/0dZcBU/Ta5vH4Qbba8sm2RNLLeHe/T u4glfkZRRey8KbPxoozRUOhsl/kXKQ8slAIcpfPZHtmEWncfkmfVPt+n BYcDKA==
workplace.gslb.schwab.com. 20   IN      RRSIG   A 8 4 20 20210311004437 20210304004437 16098 gslb.schwab.com. hdltHg4v0iOH6idgOMxXXWUSbvKeZHP3igqcERU9pMCuZWaQweIc8XEX z5QOoMhujJI9o3AdFDnBT9JVN/AQs90GbLT/SbPP6OQt2fCtVPFI+xCh 4bVVidFfFvfuTP36W7RNXc3FrfLyPJwyWRBCOHg/3UjN8E2+goVoU/Uw Ft4xmPFHJ5tYL8v7o9v/paICpSQgk7RcjjIsZZiKzN+BF8coCJNtT8DN WEohKJNt9Du+LZq8F59HjTa3g0PopOOhxu5tEzSHbs+IKPc4x3lYL25W nquvnEfVexEw81KfQB3smdi3CEY0yz/zqG8nbMb6QkxC9XQxi6b2iBbf n+JO2w==
;; Received 676 bytes from 162.93.239.1#53(gslb-anycast.schwab.com) in 46 ms

So what might be causing this problem?  The dig output seems like it is working ok?  But dig takes like 2.5 minutes to run, which does not seem normal.  I am guessing this is why unbound fails to resolve this domain and there is "No response."

On the other hand, if I try to dig a domain that unbound DOES resolve, such as "www.schwab.com," it ALSO takes like 2.5 minutes to complete.  And "www.schwab.com" resolves fine using DNSSEC turned on through the VPN tunnel.  Here is the output of DNS Lookup:

Code: [Select]

Response
Type Address
CNAME www.schwab.com.edgekey.net.
CNAME e17738.x.akamaiedge.net.
A 104.125.55.112

Resolution time per server
Server Query time
127.0.0.1 51 msec
1.1.1.1 6 msec
1.0.0.1 7 msec
Here is the output of dig "www.schwab.com".

Code: [Select]

root@OPNsense:~ # dig @127.0.0.1 www.schwab.com +trace

; <<>> DiG 9.16.10 <<>> @127.0.0.1 www.schwab.com +trace
; (1 server found)
;; global options: +cmd
.                       79654   IN      NS      j.root-servers.net.
.                       79654   IN      NS      k.root-servers.net.
.                       79654   IN      NS      l.root-servers.net.
.                       79654   IN      NS      m.root-servers.net.
.                       79654   IN      NS      a.root-servers.net.
.                       79654   IN      NS      b.root-servers.net.
.                       79654   IN      NS      c.root-servers.net.
.                       79654   IN      NS      d.root-servers.net.
.                       79654   IN      NS      e.root-servers.net.
.                       79654   IN      NS      f.root-servers.net.
.                       79654   IN      NS      g.root-servers.net.
.                       79654   IN      NS      h.root-servers.net.
.                       79654   IN      NS      i.root-servers.net.
.                       79654   IN      RRSIG   NS 8 0 518400 20210318050000 20210305040000 42351 . RGrSTUNk4Ad41ITau7wzwMrm6Uk/ReeJlR/1cul8D1bs7qdYZOeICUvX CU+j9KipCbh0VUKvbcVWXFlpWoy9k/4ay0u1ZB5BbooERfyfGVyTe4ru pXrXymKeFLetZFhUr2KoO6ITyigRPPNvJFkRhwUn6nHqgCiHEvdG2cZW FmmvFpZ+0ejIB1h7lJYg+iaG8be2tI3aXp3CF/u8Cerjii5DddESAZrL bR9K6SeeQB9GxabnQJMvFY2FXsHBps9BQkx6D1vc5Vpn8E7R4e3uIcte Rt0c7fwvOyZE1lwHsvhxIaXugLJdlSX0bWT5XwGtGFm3xo6OHuL2cqXJ 9HbxVQ==
;; Received 525 bytes from 127.0.0.1#53(127.0.0.1) in 0 ms

com.                    172800  IN      NS      l.gtld-servers.net.
com.                    172800  IN      NS      b.gtld-servers.net.
com.                    172800  IN      NS      c.gtld-servers.net.
com.                    172800  IN      NS      d.gtld-servers.net.
com.                    172800  IN      NS      e.gtld-servers.net.
com.                    172800  IN      NS      f.gtld-servers.net.
com.                    172800  IN      NS      g.gtld-servers.net.
com.                    172800  IN      NS      a.gtld-servers.net.
com.                    172800  IN      NS      h.gtld-servers.net.
com.                    172800  IN      NS      i.gtld-servers.net.
com.                    172800  IN      NS      j.gtld-servers.net.
com.                    172800  IN      NS      k.gtld-servers.net.
com.                    172800  IN      NS      m.gtld-servers.net.
com.                    86400   IN      DS      30909 8 2 E2D3C916F6DEEAC73294E8268FB5885044A833FC5459588F4A9184CF C41A5766
com.                    86400   IN      RRSIG   DS 8 1 86400 20210318050000 20210305040000 42351 . bVi/an3ya9VuX/O+2R5wTHP5+Ea7jmmQD+ZVs6rbmTpExiGl8Hsc8P+5 HSIbOcN9qcv/wnXoVwm8zLQojXWxJO4o4rkfAWI2fQ4ZvgEzZF5rxbmz DhOrXOexP7Yick8UqQpX8KADBrU6cH+jv1sYcc+pcDX0GzIq/LQV3bSa crTjtxBiqhYT8LD3d7bQ/kDbo6jyXMQTe77j2qFohW2+X3KBTpfFK6BZ iIrslY0OUYSCMqasCk9v5wSkM3qE0ebJlo71zcJVeGVaLEAEupS/HEzb ne+KSBIOMHJ3zSmZaFMXCZPSYmBAF2poNSh+L13Xpkf4Ib7w12PtWPUz BplviQ==
;; Received 1174 bytes from 192.203.230.10#53(e.root-servers.net) in 5 ms

schwab.com.             172800  IN      NS      ns1.schwab.com.
schwab.com.             172800  IN      NS      ns2.schwab.com.
schwab.com.             172800  IN      NS      ns3.schwab.com.
schwab.com.             172800  IN      NS      ns4.schwab.com.
schwab.com.             172800  IN      NS      a9-65.akam.net.
schwab.com.             172800  IN      NS      a8-64.akam.net.
schwab.com.             86400   IN      DS      3829 8 2 8B39D6D8CE4FA5D55DEB38CF05BB81E0CC087FA978AB9E0721411513 86CF2EA2
schwab.com.             86400   IN      RRSIG   DS 8 2 86400 20210309054915 20210302043915 58540 com. WCclyXLsxq4uaQpBB5WFJZvYbVNCra/EeN/AaBE+xVT0e+W9P0rJnWOM 1MdQ+FFdQDQndy9HQantJh7pOYsrroIrBDC84/MvvihnAzl0cSzUv8/1 zH95Rn0TGmyP1iGtUoBR9LTspXOy6vd6bsi3x8/J/KjzHco31YeBig1j nUSvSOG+w0gOx5XWq+1jkfh8rtIVTb8gDfDRc/muamDnNQ==
;; Received 470 bytes from 192.35.51.30#53(f.gtld-servers.net) in 21 ms

www.schwab.com.         300     IN      CNAME   www.schwab.com.edgekey.net.
www.schwab.com.         300     IN      RRSIG   CNAME 8 3 300 20210313110153 20210211103625 43563 schwab.com. eVem19JCDHIfAz3hu6smc3auF2TyWg7utEy+a43wF2Mo7cODhRsxqCvw hEffohd3bn3/INLkvuMWp7Ep4tIZD/EvQDSBzA0MYpXHUJZaCkY8j1iJ 3l2A3sO9f/ovDRAM4H0ZB6thgTErDDFpNPXVvqR2C8begFeL7M07/MZM M8eIc4tLpLDXFXKzkJk9h3Dg28xN5esKKIO7eEKS5IJEBom5YqUetHaz vwSDQQSltpHj3FR9kK6tz2AcuvtVIs/02Z0ZusbtVUNUDpozDFb3B/39 kVp87DUeFMMYaRETMAxK6lfAmlKZRpTT9cjia/qn2LkNmWzfS9qgpM4s n986XQ==
;; Received 381 bytes from 162.93.253.90#53(ns1.schwab.com) in 43 ms

ANY IDEAS? 

3

20.7 Legacy Series / HAProxy Help Needed -- Authenticated Access to Minecraft Server

« on: December 08, 2020, 07:56:24 pm »

I have a personal Minecraft server on the LAN that I run for my kids.  They want to allow cousins / school friends to play on our server.  For security reasons, I don't want to just port forward and allow public access to the Minecraft server, nor do I want these people access to my network via VPN.  I want an in between solution where people can access the Minecraft server after HTTPS user / password authentication.  I thought HAProxy would work for this, but have not gotten it to work.  Any guidance would be greatly appreciated!

End Goal:  I want people to go to some web address (e.g., https://minecraft.domain.xyz:12345) and authenticate using a user / password that I give them.  After that, they are able to connect to my server by connecting to minecraft.domain.xyz inside Minecraft.  If people do not first go to the URL to authenticate, they should not be able to connect via Minecraft.  I understand Minecraft uses port 25565.

Here is my set up so far:

1)  I installed the Let's Encrypt plugin.  I purchased my own domain (domain.xyz) and have successfully issued a wildcard certificate for domain.xyz and *.domain.xyz.  In the Let's Encrypt plugin, I do NOT check "HAProxy Integration" because I understand that is only needed if I use HTTP-01 validation and I don't use that method.

2)  I use Dynamic DNS to set domain.xyz and minecraft.domain.xyz to equal my WAN IP address.

3)  Here are my HAProxy settings:

Real Server
Enabled:  Checked
Name:  Minecraft
IP:  192.168.1.90
Port:  25565
Mode:  active [default]
SSL:  Unchecked

Backend Pool
Enabled:  Checked
Name:  Minecraft
Mode:  TCP (Layer 4)  --> my understanding is that this should be set to TCP because Minecraft is not a webserver
Balancing Algorithm:  Source-IP Hash [default]
Servers:  Minecraft
Enable Health Checking:  Checked
Health Monitor:  None
Persistence Type:  Stick-table persistence [default]
Stick-table persistence table type:  Source-IP [default]

Users / Group
I created a single test user / password.
I added this single user to a test group.

Conditions
Name:  Host_Minecraft
Condition type:  Host matches
Host string:  minecraft.domain.xyz

Name:  Auth_User
Condition type:  HTTP Basic Auth:  username/password from client matches selected user/group
Parameters:  matches to my test group.

Rules
Name:  Minecraft
Test type:  IF [default]
Selected conditions:  Auth_User AND Host_Minecraft
Execute function:  Use specified Backend Pool
Use backend pool:  Minecraft

Public Service
Name:  Frontend
Listen Addresses:  0.0.0.0:12345  I don't know if 0.0.0.0 is the right address to use here
Type:  HTTP / HTTPS (SSL offloading) [default]
Default Backend Pool:  none
Enable SSL offloading:  Checked

SSL Offloading:
Certificates:  wildcard certificate from Let's Encrypt
Default certificate:  wildcard certificate from Let's Encrypt
Enable Advanced Settings:  Unchecked

HTTP(S) settings:
Enable HTTP/2:  Checked
HTTP/2 Without TLS:  Unchecked

Basic Authentication:
Enabled:  Checked
Allowed Groups:  my test group

Firewall rules
On the WAN, I allow IPv4 TCP/UDP protocol to pass at port 12345.

Here is what happens:

1)  Using my browser, I am able to go to https://minecraft.domain.xyz:12345, it gets a user/password prompt, and I able to "login" using my test user credentials.  The connection is properly secured using the Let's Encrypt certificate.  After login, the browser shows an error message because there is no webserver at that location.  But I don't care.  I just want to satisfy the Auth_User condition.

2)  I open Minecraft and add the server minecraft.domain.xyz, and I try to connect, but it does not work.  I thought this would work because I thought this would satisfy the Host_Minecraft condition.

So what am I doing wrong?  I am able to get the user authentication working, but HAProxy is not correctly passing traffic to my Minecraft server.  I am guessing something is wrong with my "Public Server" settings, but am not sure what.

4

20.7 Legacy Series / High Packet Loss When Using VPN in OPNsense Virtualized in vSphere 7.0

« on: September 09, 2020, 06:45:09 am »

I am having a weird problem that I cannot figure out despite many hours of work. I hope someone here could give some thoughts as to why this is happening.

Background: I am running vSphere ESXi 7.0. I have a VM that is running OPNsense 20.1.9_1 (although I have also tried this with OPNsense 20.7.2 and get the same result). To be very conservative, I assigned 4 CPUs and 6 GB of RAM for this VM, and OPNsense reports that it is nowhere near using that much resources. I have two vswitches, one for the LAN and one for the WAN. On the particular LAN and WAN port associated with the OPNsense VM, I disabled all security (accept promiscuous mode, MAC address changes, and forged transmits) and I set VLAN trunking (0-4094).  I do run a few VLANs, so the VLAN trunking is needed. I don't think the reduced security is needed, but I just set everything to "accept" in case it was causing this problem. I have gigabit fiber on the WAN physical uplink, connected to the ISP gateway. Inside OPNsense Interface > Settings, I set it to disable all hardware offloading (CRC, TSO, LRO, and VLAN filtering).

Problem: Inside OPNsense, I have two gateways: one for the WAN and one through VPN (I use OpenVPN, with UDP protocol). There is no problem on the WAN gateway. I've tested large downloads that are tens of GBs from the internet and am able to get sustained full gigabit speed (around 90 MB/s) with 0% packet loss (as reported by DPINGER inside System > Gateways). So this indicates to me that there is no problem with the VM, the vswitches, or anything.

However, when I use firewall rules to direct traffic through the VPN gateway, I have problems.  If I force the download speed in the download client to be lowish, around 10 MB/s, then there is only a small amount of packet loss and the download proceeds to completion.  However, when I allow the speed to be higher, anything more than 15-20 MB/s, packet loss climbs very quickly (15 to 20% within 30 seconds, and continues to climb) and within 1-2 minutes, the VPN gateway just stops responding. The packet loss will go back down to 0% and VPN will work again if I stop the download. To be clear, the VPN connection is capable of much faster than 20 MB/s -- when I run OPNsense bare metal, I can easily get 50 MB/s on the VPN gateway with 0% packet loss.

Solutions?  So here is what is confusing me. When I run OPNsense in the VM, everything on the WAN works perfectly, at full gigabit speed with 0% packet loss. But when I direct traffic to VPN, I get huge packet loss that shuts down the gateway.

However, if I run OPNsense bare metal, I don't get any packet loss on WAN and VPN gateway. This indicates to me that the problem is not the VPN. There seems to be some weird interaction between using the VPN inside a VM that is causing the problem. I've tried everything, so what could it be?

Someone suggested that this looks like a fragmentation issue, and recommended that I play around with the MTU and MSS settings.  I've played around, but am not sure how to properly set the MTU and MSS.  There are at least three places where you can set these parameters in OPNsense that I can see:

(1)  Inside Interfaces > [VPN Interface].  Do I need to set this for WAN interface too?
(2)  Inside Firewall > Settings > Normalization.  And this section is confusing to me, and I am not sure how to properly set it.
(3)  Inside VPN > OpenVPN > Clients, where I can try to set MTU and MSS directly in the VPN connection settings.

Which of the three places should I set MTU and MSS?  Do I need to reboot every time I change these settings for them to take effect?

My MTU test:  Based on the ping test suggested on the link below, the largest ping that does not fragment is 1472, which suggests my MTU is 1500.  This is using a Windows computer whose traffic is directed through the VPN.  https://kb.netgear.com/19863/Ping-Test-to-determine-Optimal-MTU-Size-on-Router

5

20.1 Legacy Series / How to redirect domain to a custom IP address AND specific port?

« on: May 31, 2020, 11:39:17 pm »

Is there a way to redirect all LAN traffic to a particular address (e.g. www.google.com) to a particular IP at a specific port (e.g., 192.168.1.20:8000)?

I want to redirect all Google searches to this internal IP address at a non-standard port.  I'm guessing you can do this by making a custom DNS entry in unbound?  But I need the traffic directed to a particular port, and I don't think DNS does that.  I would appreciate any ideas on how to achieve this.

6

20.1 Legacy Series / Change the web proxy "access denied" page

« on: May 24, 2020, 07:42:23 pm »

I recently set up a transparent proxy to filter traffic for selected devices on the network. It works great.

But when you try to access a blacklisted page, the proxy gives this message that says "access denied" and to contact your administrator. Is there a way to customize that page to say something else?

Or even silently redirect any blacklisted page access attempts to another website randomly selected from a list?

7

19.1 Legacy Series / BIND Periodically Dying

« on: May 09, 2019, 10:39:00 pm »

Hello,

I'm using BIND to run DNSBL and it has been working great for a while.  But recently (and this coincides with upgrade to the most recent version of OpnSense), I find that BIND sometimes exits due to an error that I do not understand, and I'd have to manually restart it.  I've pasted the BIND log below (in reverse chron order).  Does anyone know why this is happening?

Is there a way to make BIND automatically restart upon exit?  Or at least get a notice that it died?

Thanks!


09-May-2019 07:46:38.754    general: critical: exiting (due to assertion failure)
09-May-2019 07:46:38.754    general: critical: #7 0x0 in ??
09-May-2019 07:46:38.754    general: critical: #6 0x3479b784c36 in ??
09-May-2019 07:46:38.754    general: critical: #5 0x14c5f2204d in ??
09-May-2019 07:46:38.754    general: critical: #4 0x14c5e53ab1 in ??
09-May-2019 07:46:38.754    general: critical: #3 0x14c5e50bd0 in ??
09-May-2019 07:46:38.754    general: critical: #2 0x14c5e4a428 in ??
09-May-2019 07:46:38.754    general: critical: #1 0x14c5f021fa in ??
09-May-2019 07:46:38.754    general: critical: #0 0x14c5d192c0 in ??
09-May-2019 07:46:38.754    general: critical: resolver.c:4895: INSIST(dns_name_issubdomain(&fctx->name, &fctx->domain)) failed, back trace
09-May-2019 07:46:38.754    lame-servers: info: FORMERR resolving 'c-0.19-a7000081.80081.1770.f17.2fc8.210.0.ig6b68dgmvuczv4udl6dz2i2g5.avts.mcafee.com/A/IN': 127.0.0.1#53
09-May-2019 07:46:38.754    resolver: notice: DNS format error from 127.0.0.1#53 resolving c-0.19-a7000081.80081.1770.f17.2fc8.210.0.ig6b68dgmvuczv4udl6dz2i2g5.avts.mcafee.com/A for client 192.168.128.237#58153: non-improving referral

8

18.1 Legacy Series / Cannot check for firmware updates

« on: July 05, 2018, 08:45:46 am »

Hello,

I keep getting this error when I try to check for firmware updates:  "Firmware status check was aborted internally. Please try again."

I've tried checking multiple times and it never works.  Is there any way to manually do this or get around this problem?  My mirror is LeaseWeb (San Francisco), LibreSSL, Production.  I've tried other  servers and get the same error.

Thanks!

9

18.1 Legacy Series / Interaction of Tor and VPN

« on: May 01, 2018, 08:17:51 am »

Hello,

I've set up a VPN client and firewall rules to redirect all non-local traffic to go out via the VPN gateway.  DNS is via unbound in resolver mode, and the outgoing interface is the VPN as well.  In effect, all non-local traffic on LAN is going out the VPN.  See attached picture of my firewall rules.

I recently set up Tor just to play around with it.  See attached Tor settings.  When I set by browser to use Sock5 proxy at the Opnsense router:9050 (see attached Firefox settings), I am successfully connecting via the Tor network (confirmed using Tor check).

My question is:  does Tor and VPN interact in this set up?  Is the Tor outgoing traffic bypassing the VPN and going to the internet via WAN?  Or is it going out via the VPN gateway?  It seems like the Tor traffic (from my browser to Opnsense router, then Opnsense router to Tor entry point) is leaving the Opnsense router via the VPN gateway.  But I'm not really sure. 

Similarly, how does DNS lookup work in this Tor setup?  In Firefox, I checked "Proxy DNS when usign SOCKS v5."  Does that mean DNS queries from my browser are all going through Tor?  Does that mean that DNS queries are bypassing unbound?

I would appreciate if someone could educate me on how this works.

Thanks!

10

18.1 Legacy Series / Weird Problem with Mutliple OpenVPN Clients

« on: April 17, 2018, 01:42:26 am »

Hello,

I'm new to OPNsense and have installed 18.1.6.  I'm a previous pfsense user and so far I'm liking OPNsense a lot.  But I'm encountering a weird issue with load balancing multiple OpenVPN clients and I hope you can help.

I have a VPN service that allows 5 concurrent connections.  Historically, I would connect 4 clients from the router, then load balance between the 4 gateways to increase total throughput (I have gigabit fiber so I could actually use the speed from concurrent connections).

The problem is that when I try to do this in OPNsense, I'm not getting any connections (or unstable connections).  I thought maybe I played with the settings too much in the process of getting familiar with OPNsense, so I started from scratch again (reformat, clean reinstall, then update to 18.1.6).  I went step by step to setup the various settings. 

Here is the set up.  So far, I have made minimal changes to the settings (basically, just standard things in the System section).  I have setup the WAN, LAN, OPT1 and OPT2 interfaces, which are the four ethernet ports on my router.  I have NOT made any changes to the Firewall section -- just the standard settings that allow everything through on the LAN.  The internet on the LAN port works fine.

Then I go and set up two OpenVPN servers (I run two servers, one on TCP 443 and one on UDP 80, for me to connect remotely into my home network).  I then set up three OpenVPN clients to my VPN service.  They all connect fine (and to be clear, I connect to my VPN service in such a way that the virtual addresses of the three client connections are in distinct subnets so that they would not share the same gateway).

Here is where the problem starts.  I noticed that I can get internet service on my LAN port only if I have 1 or 2 VPN clients running, but NOT if I have 3 VPN clients running.  I noticed this because I was surfing the web and it stopped when I connected the third client.  I thought it was weird, so I tried to disconnect one of them.  Sure enough, I'm able to surf on the LAN port if I have 2 clients (doesn't matter which two, I have tried all the combinations), but not if I have 3 clients. 

I don't understand why this would happen, especially since right now, I have NOT defined interfaces for the 3 VPN clients (i.e., there are no gateways associated with the three clients), and my firewall rules do NOT attempt to pass any traffic through the VPN client connections.  Also, I have not changed the Unbound settings (the outgoing network interface is the default "all").

In theory, the OpenVPN clients should not affect anything because they're just connected and sitting there, not being used.  But it seems like somehow they do affect something, but I am not sure what.  I do not see any obvious errors.

I appreciate any help you can give me.