pia-foss / manual-connections

Scripts for manual connections to Private Internet Access
MIT License
631 stars 169 forks source link

series of errors in FreeBSD (FreeNAS) jail #30

Closed glorious1 closed 3 years ago

glorious1 commented 4 years ago

I got a series of errors I can't figure out how to deal with in a FreeBSD/FreeNAS jail. They have to do with

  1. sysctrl command trying to disable the ipv6 thing that apparently doesn't exist.
  2. There is no 'ip' command, and none also in the pkg repository.
  3. Something with tun06? I don't understand the output. I think my openvpn normally uses tun0

I think the other errors are cascades from those. Obviously I am less advanced than most git-hubbers.

Some things I hardcoded into run_setup.sh to avoid tedium while testing: PIA_USER='****' PIA_PASS='****' export PIA_USER export PIA_PASS protocol="tcp" encryption="standard" PIAAUTOCONNECT="openvpn${protocol}_${encryption}" export PIA_AUTOCONNECT PIA_DNS="false" export PIA_DNS PIA_PF="true" export PIA_PF MAX_LATENCY=0.05 export MAX_LATENCY

run_setup.sh: sysctl: unknown oid 'net.ipv6.conf.all.disable_ipv6' sysctl: unknown oid 'net.ipv6.conf.default.disable_ipv6' . . . ./connect_to_openvpn_with_token.sh: line 40: ip: command not found The tun06 adapter already exists, that interface is required for this configuration. sysctl: unknown oid 'net.ipv6.conf.all.disable_ipv6' ./connect_to_openvpn_with_token.sh: line 69: [: -ne: unary operator expected sysctl: unknown oid 'net.ipv6.conf.default.disable_ipv6' ./connect_to_openvpn_with_token.sh: line 70: [: -ne: unary operator expected Trying to write /opt/piavpn-manual/pia.ovpn... . . . Confirming OpenVPN connection state... cat: /opt/piavpn-manual/route_info: No such file or directory The VPN connection was not established within 10 seconds. ./connect_to_openvpn_with_token.sh: line 194: kill: (89709) - No such process

g00nix commented 4 years ago

This is not the first time I see reports of troubles with FreeBSD. The best thing I can do now is to add a note in the README specifying that FreeBSD will require some tweaks to make everything work.

As a long term solution, we will have to create a fork or a branch dedicated to FreeBSD.

glorious1 commented 4 years ago

Thanks. Can you suggest what tweaks might work. Like the sysctrl command and a substitute for ‘ip’?

On Nov 1, 2020, at 7:59 AM, goonix notifications@github.com wrote:

This is not the first time I see reports of troubles with FreeBSD. The best thing I can do now is to add a note in the README specifying that FreeBSD will require some tweaks to make everything work.

As a long term solution, we will have to create a fork or a branch dedicated to FreeBSD.

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/pia-foss/manual-connections/issues/30#issuecomment-720110377, or unsubscribe https://github.com/notifications/unsubscribe-auth/ABNZ5QPZSDDTB2XVCYPCOHLSNWAULANCNFSM4TGEA3KQ.

g00nix commented 4 years ago

Can you suggest what tweaks might work

I am not a FreeBSD user, but I did see comments from other FreeBSD users that made it work: @dundunn @abraithwaite @mstargard

I hope you guys don't mind me tagging you. I know you all use FreeBSD and I think it would make sense to work together to create a fork that works out of the box on FreeBSD.

glorious1 commented 4 years ago

Thanks I did see some of their posts but nothing that would help me edit the script so far.

I did work out one thing related to the ip command and using the result in an if statement. In connect_to_openvpn_with_token.sh, lines 40 and 41 can be deleted, and line 43 replaced with if ifconfig tun06; then It just uses the return value of the command instead of creating a couple of variables and comparing them. I'm guessing the same could be done with the ip command.

Sorry I don't know how to fork and stuff; hopefully one of the brighter FreeBSD users can do that.

dundunn commented 4 years ago

I use Wireguard so I didn't run into that issue but it's same for me. OpenVPN can't establish a connection.

The sysctl errors don't matter. You can delete that part from connect_to_openvpn_with_token.sh because you disable IPv6 via /etc/rc.conf on FreeBSD.

glorious1 commented 4 years ago

Thanks dundunn, that's good info to me about sysctl.

I made some further progress - FreeBSD can't make a tun06 connection. I changed that to tun1 in wherever-you-put-the-scripts/openvpn_config/standard.ovpn (or strong if you're using that one) and that error doesn't occur anymore.

But at the end, I'm still getting `The OpenVPN connect command was issued.

Confirming OpenVPN connection state... cat: /opt/piavpn-manual/route_info: No such file or directory The VPN connection was not established within 10 seconds. ./connect_to_openvpn_with_token.sh: line 193: kill: (45987) - No such process`

The last few lines of /opt/piavpn-manual/debug_info are Sun Nov 1 14:41:55 2020 TUN/TAP device /dev/tun1 opened Sun Nov 1 14:41:55 2020 /sbin/ifconfig tun1 10.7.111.2 10.7.111.1 mtu 1500 netmask 255.255.255.0 up add net 10.7.111.0: gateway 10.7.111.1 Sun Nov 1 14:41:55 2020 /opt/piavpn-manual/openvpn_up.sh tun1 1500 1560 10.7.111.2 255.255.255.0 init Sun Nov 1 14:41:55 2020 WARNING: Failed running command (--up/--down): could not execute external program Sun Nov 1 14:41:55 2020 Exiting due to fatal error

iPherian commented 4 years ago

@glorious1 out of curiosity, why can't FreeBSD use tun06? (never used FreeBSD myself)

glorious1 commented 4 years ago

I don’t know, it just gives an error. Probably tun6 would work, but I know tun1 does. The default tun that used to be created in the PIA-OpenVPN good old days, when all these scripts were not needed, was tun0.

On Nov 1, 2020, at 3:18 PM, iPherian notifications@github.com wrote:

@glorious1 https://github.com/glorious1 out of curiosity, why can't FreeBSD use tun06? (never used it myself)

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/pia-foss/manual-connections/issues/30#issuecomment-720167542, or unsubscribe https://github.com/notifications/unsubscribe-auth/ABNZ5QMZFTCBWYBCKILKC2TSNXUCVANCNFSM4TGEA3KQ.

Mannekino commented 4 years ago

Is there any way to manually get these pieces of information so I can run the script for port forwarding? I'm trying to use this inside a FreeNAS Jail.

PF_GATEWAY - the IP of your gateway PF_HOSTNAME - name of the host used for SSL/TLS certificate verification PIA_TOKEN - the token you use to connect to the vpn services

g00nix commented 4 years ago

@Mannekino

PF_GATEWAY

OpenVPN: https://github.com/pia-foss/manual-connections/blob/master/connect_to_openvpn_with_token.sh#L189 WireGuard: https://github.com/pia-foss/manual-connections/blob/master/connect_to_wireguard_with_token.sh#L159

PF_HOSTNAME

For PF you can use -k, or get the hostname of the server you connected to as it can be seen here: https://github.com/pia-foss/manual-connections/blob/master/get_region_and_token.sh#L118-L125

PIA_TOKEN

This is how you get a token: https://github.com/pia-foss/manual-connections/blob/master/get_region_and_token.sh#L149-L154 If you already connected to the VPN, the meta API can be used via 10.0.0.1 to get a token via https://10.0.0.1/authv3/generateToken

Mannekino commented 4 years ago

@Mannekino

PF_GATEWAY

OpenVPN: https://github.com/pia-foss/manual-connections/blob/master/connect_to_openvpn_with_token.sh#L189 WireGuard: https://github.com/pia-foss/manual-connections/blob/master/connect_to_wireguard_with_token.sh#L159

PF_HOSTNAME

For PF you can use -k, or get the hostname of the server you connected to as it can be seen here: https://github.com/pia-foss/manual-connections/blob/master/get_region_and_token.sh#L118-L125

PIA_TOKEN

This is how you get a token: https://github.com/pia-foss/manual-connections/blob/master/get_region_and_token.sh#L149-L154 If you already connected to the VPN, the meta API can be used via 10.0.0.1 to get a token via https://10.0.0.1/authv3/generateToken

Thank you, this seems a bit beyond my understanding unfortunately. I haven't switched over yet to the nextgen servers because I can't get the port forwarding to work with that. I'm still using an older script that sets port forwarding and automatically changes the incoming port on Transmission. That script no longer works when I switch to the nextgen servers.

I did have to add a setting to my OpenVPN configuration file after updating my FreeNAS Jail to OpenVPN 2.5. I had to add data-ciphers BF-CBC but now I'm getting warnings this might be insecure and vulnerable to SWEET32 attacks or something. Also the command ip does not work inside a Jail.

I'm happy to test any changes to the scripts you might have.

g00nix commented 4 years ago

@Mannekino

Mannekino commented 4 years ago

Someone on the TrueNAS has been extremely helpful so far. See:

I've managed to get a OpenVPN 2.5 connection established with the nextgen servers using the PIA configuration files. The person who helped me has made his own port forwarding script which worked for me, it can be found here:

https://github.com/dak180/TrueNAS-Scripts/blob/master/pia-port-foward.sh

Unfortunately it's not working quite as expected. I think when using the nextgen servers IPv6 is enabled somehow. I have very little understanding of this but I'm getting the following error messages in the log and after a couple minutes the port is no longer open on Transmission.

Errors after starting OpenVPN:

Nov  3 12:55:34 transmission2 openvpn[99294]: GDG6: problem writing to routing socket: No such process (errno=3)
Nov  3 12:55:34 transmission2 openvpn[99294]: TUN/TAP device /dev/tun0 opened
Nov  3 12:55:34 transmission2 openvpn[99294]: /sbin/ifconfig tun0 xxx.xxx.xxx.xxx xxx.xxx.xxx.xxx mtu 1500 netmask 255.255.255.0 up
Nov  3 12:55:34 transmission2 openvpn[99294]: WARNING: OpenVPN was configured to add an IPv6 route. However, no IPv6 has been configured for tun0, therefore the route installation may fail or may not work as expected.
Nov  3 12:55:34 transmission2 openvpn[99294]: add_route_ipv6(2000::/3 -> :: metric -1) dev tun0

And these error keep repeating a lot:

Nov  3 12:26:18 transmission2 transmission-daemon[21795]: Couldn't connect socket 53 to 2001:xxxx:xxxx:xxxx:xxxx:xxxx:xxxx:xxxx, port xxxxx (errno 49 - Can't assign requested address) (/wrkdirs/usr/ports/net-p2p/transmission-daemon/work/transmission-3.00/libtransmission/net.c:340)
Nov  3 12:26:21 transmission2 transmission-daemon[21795]: Couldn't connect socket 50 to 2001:xxxx:xxxx:xxxx:xxxx:xxxx:xxxx:xxxx, port xxxxx (errno 49 - Can't assign requested address) (/wrkdirs/usr/ports/net-p2p/transmission-daemon/work/transmission-3.00/libtransmission/net.c:340)
Nov  3 12:26:22 transmission2 openvpn[96198]: AEAD Decrypt error: bad packet ID (may be a replay): [ #808615 ] -- see the man page entry for --no-replay and --replay-window for more info or silence this warning with --mute-replay-warnings
Nov  3 12:26:22 transmission2 openvpn[96198]: AEAD Decrypt error: bad packet ID (may be a replay): [ #808616 ] -- see the man page entry for --no-replay and --replay-window for more info or silence this warning with --mute-replay-warnings

Not sure how to proceed. I think I would like to enable IPv6 as I am not using it but I tried to find ways how to disable this in the OpenVPN configuration file but haven't been able to find anything.

g00nix commented 4 years ago

I've managed to get a OpenVPN 2.5 connection established with the nextgen servers using the PIA configuration files.

At this point, 25% of the fleet has support for OpenVPN 2.5.0, so you probably got lucky and hit a server that already got upgraded.

The person who helped me has made his own port forwarding script which worked for me, it can be found here:

https://github.com/dak180/TrueNAS-Scripts/blob/master/pia-port-foward.sh

This scripts does what it should do, however it could use some refactoring. :smile:

Unfortunately it's not working quite as expected. I think when using the nextgen servers IPv6 is enabled somehow.

Please try to shut IPv6 down on OS level.

Mannekino commented 4 years ago

At this point, 25% of the fleet has support for OpenVPN 2.5.0, so you probably got lucky and hit a server that already got upgraded.

I'm using the Berlin location that I've been using for a while now.

Please try to shut IPv6 down on OS level.

I'm trying to figure out how to do this, preferably on the Jail level, but maybe it has to be for my entire FreeNAS server.

g00nix commented 4 years ago

I'm using the Berlin location that I've been using for a while now.

I checked now. Half the servers from Berlin support 2.5.0.

dundunn commented 4 years ago

I'm trying to figure out how to do this, preferably on the Jail level, but maybe it has to be for my entire FreeNAS server.

You can disable it via rc.conf or you rebuild the kernel without the IPv6 feature. The latter might have other side effects. https://forums.freebsd.org/threads/completely-disable-ipv6-in-freebsd-10.50569/

glorious1 commented 4 years ago

You can disable it via rc.conf or you rebuild the kernel without the IPv6 feature. The latter might have other side effects. https://forums.freebsd.org/threads/completely-disable-ipv6-in-freebsd-10.50569/

In /etc/rc.conf I added WITHOUT_IPV6="YES" and I edited ipv6_activate_all_interfaces="YES" to say "NO".

I restarted the jail, and netstat -nr still shows a bunch of ipv6 stuff: Internet6: Destination Gateway Flags Netif Expire ::/96 ::1 UGRS lo0 ::1 link#1 UH lo0 ::ffff:0.0.0.0/96 ::1 UGRS lo0 fe80::/10 ::1 UGRS lo0 fe80::%lo0/64 link#1 U lo0 fe80::1%lo0 link#1 UHS lo0 ff02::/16 ::1 UGRS lo0

ifconfig still shows one thing that appears to be ipv6: lo0: flags=8049<UP,LOOPBACK,RUNNING,MULTICAST> metric 0 mtu 16384 options=680003<RXCSUM,TXCSUM,LINKSTATE,RXCSUM_IPV6,TXCSUM_IPV6> inet6 ::1 prefixlen 128 inet6 fe80::1%lo0 prefixlen 64 scopeid 0x1 inet 127.0.0.1 netmask 0xff000000 nd6 options=21<PERFORMNUD,AUTO_LINKLOCAL> groups: lo

Does this mean ipv6 is still enabled somehow?

Mannekino commented 4 years ago

@glorious1 I haven't been able to figure it out either. I've been trying to disable IPv6 inside my FreeNAS Transmission Jail for 3 hours now trying everything I could find. There seems to be a couple of configuration options also on the Jail level, namely:

I'm giving up for the time being. Maybe I should try and get IPv6 to work instead but I have no idea how to go about that. I don't even know if I have IPv6 ability from my ISP.

dundunn commented 4 years ago

I didn't know the building process can be that exhausting but I think that would be the only way to disable IPv6 entirely. You would have to build FreeBSD first with WITHOUT_INET6=yes in the src.conf and then build FreeNAS on top of it. But I'm not sure if that's even possible without further tweaks.

Those addresses are loopback addresses so they shouldn't be available anywhere outside the FreeNAS system. I'm not sure if that's entirely true but the explanation of the user kpa, on why you shouldn't worry too much about those addresses still being active, strengthens my assumption that disabling IPv6 by rc.conf should be sufficient to advert leaks. But I'm not an expert and I didn't understand every part of his post. I also have to learn more about networking and especially IPv6 to understand on how to test if a device leaks private addresses, so it might be better if someone with more knowledge can give a better explanation on that particular issue.

But I also think a GIthub repository for PIA users is not the place to discuss this kind of issue. The iXsystems forums might be a better place for that.

Mannekino commented 4 years ago

I managed to fix all the issues I was having with the update to OpenVPN 2.5. Hopefully the solutions are solid. I will check the logs tomorrow. So far, so good. I'm running FreeNAS-11.3-U5 and my Jails are at 11.4-RELEASE.

Here is what I did to solve everything:

I used the PIA 4th generation strong encryption configuration file

https://www.privateinternetaccess.com/helpdesk/kb/articles/where-can-i-find-your-ovpn-files

In particular I'm using the Berlin server to connect to.

For port forwarding I used the following script

https://github.com/dak180/TrueNAS-Scripts/blob/master/pia-port-foward.sh

I made some minor changes because I'm using authentication for my Transmission instance. So I added a transUser and transPass variable at the top after the other variables:

transUser=[username]
transPass=[password]

And everywhere in the script where transmission-remote is invoked I added the following right after transmission-remote:

--auth "${transUser}":"${transPass}"

To get rid of the IPv6 errors I changed the OpenVPN configuration file

Thanks to another user on the TrueNAS forums I solved the IPv6 problems: https://www.truenas.com/community/threads/pia-and-openvpn-v2-5.88459/#post-613168

Right before the line that starts with <crl-verify> I added the following two lines:

pull-filter ignore "ifconfig-ipv6"
pull-filter ignore "route-ipv6 "

To get rid of a cipher warning I changed this

I still got some warning about the ciphers. The solution was in the warning itself. Right after the cipher line in the configuration file I added this line:

data-ciphers aes-256-cbc

To make sure the port stays forwarded I added a cronjob to FreeNAS

Using the GUI of FreeNAS I added a cronjob that runs the above mentioned script every 10 minutes to refresh the port forwarding. I noticed the port closed after 15 minutes in Transmission.

iocage exec [jailname] [path_to_script]/pia-port-foward.sh

If I did anything wrong, or if I can improve on anything please let me know.

glorious1 commented 4 years ago

Wow, congratulations @Mannekino ! Your post is a lot to process. For starters, is the ovpn configuration file for UDP or TCP? Or maybe it doesn't matter. I'm also curious how these configuration files differ from the ones included with the pia-foss/manual-connection scripts.

It looks like you took a big departure from these manual-connection scripts. I was trying to use them while making necessary modifications, but my favorite approach is doing what works!

g00nix commented 4 years ago

@Mannekino Here is my personal point of view on what you should do next:

  1. create a repo for enabling PF on FreeNAS
  2. make everything you discovered work as part of one script that feels like a magical automation
  3. refactor the script till it is easy to ready for everybody
  4. enjoy the stars you get on github

I really hope you will have time to do that. We are also looking internally at providing improved support for FreeBSD. We would like to see FreeBSD get more market share and having bad automation for FreeBSD is not setting a good example. That being said, time is also limited so I don't know when we will get to this. It will definitely happen in the future, but I don't know when.

ghost commented 4 years ago

Thanks for this @Mannekino. Took a couple extra tweaks, but this works for me as well.

Mannekino commented 4 years ago

@g00nix I'm not very good at writing scripts. Also, in the end it took quite some time but the fixes itself aren't that complicated. But I really have very little understanding how I fixed it. I just tried stuff other people suggested. The port forwarding script is not mine either.

Edit I think I'm still hitting a server sometimes that hasn't been updated to nextgen yet like you said might happen. I've restarted OpenVPN a couple times and sometimes I get the error message about the cipher. I assume this happens when I hit an old server?

OPTIONS ERROR: failed to negotiate cipher with server.  Add the server's cipher ('BF-CBC') to --data-ciphers (currently 'AES-256-CBC') if you want to connect to this server.

I got that with server [berlin408] now getting server [berlin418] and that one is working.

glorious1 commented 4 years ago

@g00nix , I'm working on a fork at glorious1/manual-connections. I wanted to stick with your scripts as much as I could. It's still a bit messy, but I finally got it working! The last problem was in the config file I was trying to specify a tun number as it originally did (tun06 to tun 1) but I saw in the config files that Mannekino linked to, they just say 'tun', and that worked. Also needed to install base64 (not built in). Had to abandon the date-time conversion for the expiration date - it doesn't work in FreeBSD date and I'm not sure what it's even doing.

I haven't yet tried to connect transmission to it, but everything reports success! Thanks to @Mannekino also for the tip about those pull-filter things in the config file.

FYI, I commented out most everything in run_setup.sh and just hardwired everything (except user/pass) like a setup config file. So much easier!

dr-diem commented 4 years ago

@glorious1 thanks for this! I was just starting to redeploy for NextGen on my FreeNAS box and came upon this issue by chance :o) One question - FreeBSD uses tcsh by default (or at least mine does?) - did you alter your Transmission jail to use bash instead to be able to run these scripts?

ghost commented 4 years ago

pretty simple I just installed bash in my jail pkg install bash

dr-diem commented 4 years ago

Ok cool, thanks for the confirmation.

glorious1 commented 4 years ago

@dr-diem you can just do pkg install bash curl jq base64 to get everything needed for the scripts (assuming you already have openvpn and transmission).

I recently added a command to port_forwarding.sh to send the port number to transmission so it gets synced up. But I'm just realizing that should probably go inside the 15 minute port-refresh loop so it gets resent in case transmission gets rebooted.

Actually I'm thinking about separating out that 15-minute loop as a separate script that gets called after the rest of port_forwarding.sh runs, but thereafter by a cron job every 15 minutes so the script doesn't have to keep running forever. @g00nix do you think that would be OK?

dr-diem commented 4 years ago

@glorious1 I agree with your approach, on the basis that I prefer to run OpenVPN as service (for all the usual reasons) and so I want to set up the port only once connected. I played with using the 'up' script but didn't get much success (this might be a Gentoo issue to be fair) so I am instead working on a separate script that will work post-connection, that obtains a token and uses it to request then set up a port, with the intent to configure Transmission thereafter. Testing on Gentoo, but will migrate it to FreeBSD once it's working.

Side note - I cannot raise issues at your repo - did you disable the feature or is it just me?

glorious1 commented 4 years ago

@dr-diem Looks like Issues were turned off by default so I just turned that on. I went ahead and separated out the 15-minute stuff in refresh_pia_port.sh and that's all working now, at least for me. I don't quite follow what you mean by running OpenVPN as a service, and setting up the port after being connected. For me OpenVPN will be running all the time, and whether the port gets assigned before or after starting OpenVPN doesn't really matter.

dr-diem commented 4 years ago

Nice! Your question concerning instantiating OpenVPN as a service has served to focus my mind, and made me realise that my end goal differs somewhat from that of these scripts. Simply put, I want to use an OS-integrated method - services (BSD init.d scripts or Linux rc.d scripts) - to start and stop the connection, then custom scripting only to set up the port forwarding and configure Transmission.

To set up a port we need an auth token. The set of scripts in this repo obtain the authentication token before connecting the VPN, whereas in my case the VPN is already up by the time I want to configure the port. @g00nix very helpfully mentioned earlier in this thread that the meta-services server is available at 10.0.0.1 once connected.

I'm working on a set of scripts that leverage what these (plus your FreeBSD insights!) have taught me. When they're in a fit state I'll see whether they deserve pull requests to these repos or have diverged so much as to be published separately.

glorious1 commented 4 years ago

Maybe you'll be interested in this iPherian fork that talks about making it a service. Frankly that stuff is beyond me and I don't know how those scripts work. But maybe you could take that and make the BSD modifications if needed.

dr-diem commented 4 years ago

Thanks for the pointer. As it goes iPherian is targeting systemd, which is the 'modern Linux' way of running services, and wholly incompatible with BSD. Mine should be a nice complement, in that it'll target BSD and the prior Linux approach, since they were broadly similar.

dr-diem commented 4 years ago

So, after a long process of developing the algorithm and rearranging the elements of the PIA scripts to make a single cron-callable script that can handle re-authentication to obtain a token, payload and signature when these items expire, then set up the port and configure Transmission, I realised that dak180's script discovered by @Mannekino does everything necessary, including restarting the VPN if it has disconnected. Even when the port expires in two months it would be detected and a new port configured. Even better, the only pre-configured variables it needs are the PIA username and password stored in a root-readable file, and the username that Transmission starts up with.

For a FreeBSD server implementation I find dak180's script to be more appropriate and robust. One can use run_setup.sh one time to generate an ovpn file, configure Openvpn to use that file to connect, then configure the script as a cron every 15 minutes as @Mannekino wrote, and PIA is configured indefinitely.

dak180 commented 4 years ago

For a FreeBSD server implementation I find dak180's script to be more appropriate and robust. One can use run_setup.sh one time to generate an ovpn file, configure Openvpn to use that file to connect, then configure the script as a cron every 15 minutes as @Mannekino wrote, and PIA is configured indefinitely.

@dr-diem thanks; the general goal of my script is to not care about the Openvpn connection as long as it is up and to run off of a cron script, though you could easily run it as often as every 2 minutes and it should still do the right thing.

g00nix commented 3 years ago

I added a section to the README with the repos you guys created: https://github.com/pia-foss/manual-connections#3rd-party-repositories

g00nix commented 3 years ago

This issue has been quiet for a while now. Are you guys happy with the 3rd Party repos? Do you think we can close this issue at this point?

glorious1 commented 3 years ago

That’s fine with me, thank you.

On Dec 2, 2020, at 4:21 PM, goonix notifications@github.com wrote:

This issue has been quiet for a while now. Are you guys happy with the 3rd Party repos? Do you think we can close this issue at this point?

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/pia-foss/manual-connections/issues/30#issuecomment-737576102, or unsubscribe https://github.com/notifications/unsubscribe-auth/ABNZ5QJWBDJXBGX36FS5CRDSS3KXZANCNFSM4TGEA3KQ.