Menu

Show posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.

Show posts Menu

Messages - dudeman21

#1
General Discussion / Re: Backup: Nextcloud configuration
February 02, 2023, 02:46:05 PM
I'm having similar issues. I was running opnsense 21 and nextcloud backup was working without issue when it was a default option in the backup GUI. I just updated to 23 and installed the nextcloud plugin, now it doesn't work with the same settings.

I have a nextcloud instance that is working correctly with a lets encrypt certificate. I remade the app password incase that was the issue. I also told it to use another directory since the default backup directory is what was previously being used and had lots of backup files already. None of these options worked.

2023-02-02T05:40:53-08:00 Error php-cgi Check Nextcloud configuration parameters
2023-02-02T05:40:53-08:00 Error php-cgi {"url":"https:\/\/nextcloud.redacted.ca:8443\/remote.php\/dav\/files\/apps\/","content_type":null,"http_code":0,"header_size":0,"request_size":0,"filetime":-1,"ssl_verify_result":0,"redirect_count":0,"total_time":60.01651,"namelookup_time":0.000639,"connect_time":0,"pretransfer_time":0,"size_upload":0,"size_download":0,"speed_download":0,"speed_upload":0,"download_content_length":-1,"upload_content_length":-1,"starttransfer_time":0,"redirect_time":0,"redirect_url":"","primary_ip":"","certinfo":[],"primary_port":0,"local_ip":"","local_port":0,"http_version":0,"protocol":0,"ssl_verifyresult":0,"scheme":"","appconnect_time_us":0,"connect_time_us":0,"namelookup_time_us":639,"pretransfer_time_us":0,"redirect_time_us":0,"starttransfer_time_us":0,"total_time_us":60016510}
2023-02-02T05:40:53-08:00 Error php-cgi Error while fetching filelist from Nextcloud '/.' path


anyone know why it would be working before but not with the new nextcloud plugin?
#2


Quote from: Northguy on January 25, 2020, 10:09:47 AM
Quote from: Northguy on January 24, 2020, 12:29:19 PM
It will work if you put a NAT loopback on the outbound NAT. Need to come back later with screenshots (not in the opportunity right now). You could also google on hairpin nat to see if you can come up with the solution yourself.


Hi,

Create a port forward like this (NAT Port forward):
Interface: LAN
Protocol: TCP/UDP
Source: invert -> 192.168.1.22
Source Port: Any
Destination: invert -> LAN ADDRESS
Destination Port: DNS
Redirect Target: 192.168.1.22
Redirect Port: DNS
Nat Reflection: Disabled

Create an outbound NAT translation like this (NAT Outbound):
Interface: LAN
Protocol: any
Source: invert -> 192.168.1.22
Source Port: Any
Destination: 192.168.1.22
Destination Port: DNS
Translation/Target: interface address

This should do the trick. One drawback is that in pihole you will see all redirected traffic coming from OPNsense instead of your client.

When configuring a hard coded DNS like 1.1.1.1 and using nslookup, it still shows that 1.1.1.1 is resolving the DNS, but actually you will find an entry in pihole.

Maybe it can be done in an easier way. Open to suggestions.


Thank you so much for this! It works perfectly. I can now do ''nslookup car.com 1.1.1.1" and it will show up in the pi-hole logs.

Just a note for the noobs like me: when setting a specific IP address like 192.168.1.22 if there is a box next to it, set it to /32. (32 specifies a specific IP address).

Also this seemed to work better if for the out bound NAT rule I set the source port to DNS (53) instead of any. But for the port forward rule I kept it exactly as you said.

As far as the IP address all looking like it came from the router, that is true but only for clients that are not respecting the DHCP settings in the first place and have hard coded DNS servers set, so that is an ok compromise. Most clients show up correctly with the above settings because they have their DNS server set to 192.168.1.22 to begin with.

Thanks again for your help!
#3
Quoteyou have to build a rule that all DNS requests from your LAN are forwarded to your pihole IP.
then that should work, I think.

I thought that's what I thought I had with the port forward rule, is there another rule I need to make?  The port forward rule automatically creates a rule on the LAN interface which I have placed at the very top to get first priority. Any idea what else I need? Thanks.
#4
The pihole already works correctly in terms of being pushed to users via DHCP. I want to setup a rule to force some devices that have hard coded DNS servers and don't respect the DHCP settings.

The idea being that the router will intercept any packets going on port 53 that are trying to leave the LAN network and port forward them to the pihole. Of course the pihole needs to be able to communicate with an external DNS, so the source IP is inverted to that traffic coming from the pihole is not affected.

My thinking is as follow:

All traffic on port 53 trying to leave the LAN network should be redirected to 192.168.1.22 (pihole) with the exception of traffic originating from the pihole itself, in which case it should be able to access an external DNS server (such as 8.8.8.8 ). I've experimented with the destination being !192.168.1.22 and also !LANADDRESS and neither works.

Here is a full screenshot of the port forward settings. After making this rule, I have moved the rule to the top of the LAN firewall rules (just under the automatic rules)

https://imgur.com/hiNioe4
#5
I'm trying to have all DNS traffic on my LAN redirected to my pihole. I've looked at several guides and tutorials and I think I have it setup properly but it doesn't seem to work.

My pihole is on 192.168.1.22

My Port Forward rule is (see screenshot):

Interface: LAN
Protocol: TCP/UDP
Source: invert -> 192.168.1.22
Source Port: DNS
Destination: invert -> LAN ADDRESS
Destination Port: DNS
Redirect Target: 192.168.1.22
Redirect Port: DNS
Nat Reflection: Disabled

https://imgur.com/UnEzcka

In the firewall rules LAN interface, I moved the rule that was created to the top (just under the automatic rules).

When I run 'nslookup test.com 192.168.1.22' I can see the lookup in the pihole logs. But when I run 'nslookup car.com 8.8.8.8', I don't see the lookup in the pihole logs meaning that it was able to look up directly to 8.8.8.8 and bypass the pihole.

Is there anything that I'm missing?

Thanks.



#6
Thank you for the replies.

QuoteIt is AES encrypted with your Nextcloud key.
1. How do I decrypt the backup file? The password I used in the backup settings to authenticate my nextcloud was the user and a one time password I generated from the nextcloud GUI. Also the encrypted file I just made below is 86kb, the equivalent non encrypted file is 2mb.

2.
File name in nextcloud: config-xxx-2018-06-25_01:06:36.xml

current date and time as shown on the dashboard: Mon Jun 25 13:03:38 PDT 2018

The dashboard time is correct as confirmed by my windows machine and cell phone. Note, I copied and pasted the dashboard time just 1-2 s after hitting the backup button. If it is a different time zone, I don't know why it would be 3 mins off. 30mins might make sense for certain timezones. Also 24h time would be nice, not sure it it's 33 mins off or 12hrs off. Thanks.
#7
The new nextcloud backup appears to work, I put in the URL, username and password, and it correctly makes a folder and uploads an XML file. There are two issues.

1. The uploaded files appear to be encrypted/corrupted?
If I manually download a backup file, it shows a nice plain text XML file with all the settings that are readable. However the files that are uploaded to nextcloud are just giant blocks of characters, it looks like it might be encrypted but there's no option to actually choose encryption or even choose a password. (also the nextcloud files are only 73kb whereas the manual files are 2mb for me as they contain key files).

2. The time stamp on the created file is not correct. The dashboard on opnsense shows the correct time, the date on the filename is correct, but the part after that has the incorrect time stamp.

That being said, thank you to the devs for the nextcloud feature, looks very promising.
#8
sorry for the long delay for my reply, I really appreciate your help. It turns out it was my ISP blocking everything on port 80 and 443. For anyone else reading this in the future: google to see if your ISP is blocking ports. If they are you have to use something else like 444....BUT I was using cloudflare DNS which by default doesn't allow HTTPS over a non standard port (https://support.cloudflare.com/hc/en-us/articles/200169156-Which-ports-will-Cloudflare-work-with-). You can easily fix this by using a port mentioned in that article like 8443 or shut off their proxying by clicking the yellow cloud in your DNS settings.

Note, I did have the incorrect NAT settings in OPNsense to begin with so thanks for helping me fix that. After that it was mostly a DNS issue, like it always is :)

Also for future readers, the live filter view on the firewall logs is much more useful if you use Boolean operators like | for OR. So if you want to see multiple IPs, do something like:

192.168.1.2|192.168.1.10|250.555.555.555, etc...
#9
I tried changing the rules, Let's Encrypt still can't access the NGINX server. Says likely firewall blocking.

I want port 80 coming in from the wan to forward to port 81 on 192.168.1.31.

Same for HTTPS, WAN:443->192.168.1.31:444



I must be missing something incredibly simple, I just can't figure it out. Thanks!
#10
Hello all,

I've been searching various forums for a while now and I can't find the answer to what I'm doing wrong.

What I want to do: access services that I run on my unraid server behind opnsense such as nextcloud using a public IP address over HTTPS, ex: nextcloud.example.com. The issue seems to be opnsense sending the requests to the WEB GUI instead of the NGINX server. I'm running the NGINX in an UNRaid docker on port 81 (HTTP) and 443(HTTPS) to avoid conflicts with the unraid web gui. I want to be able to type https://nextcloud.example.com and have it automatically redirect from 443 to port 444 on my local NGINX IP address.

On my DNS account at namecheap for example.com, I have:




TypeHostValue
A+DDNS@WAN IP (108.x.x.x)
CNAMEnextcloudexample.com.

using nslookup, example.com and nextcloud.example.com correctly resolve to my WAN IP.

On OPNSense I have the following NAT->port forward settings:


when I type example.com from within the network, I get to the opnsense web gui and it gives an error "Potential DNS rebind attack". When I go to example.com from outside (on my phone's data), I get connection time out.

as a test, I changed to web gui to use port 445 as HTTPS, and if I go to example.com from within my network, it redirects to example.com:445, indicating the web gui is capturing the request. From outside, I just get connection timeout.

On my unraid Let'd Encrypt-NGINX docker, I get: "Timeout during connect (likely firewall problem)" on all the domains and subdomains it tries.

I'm pretty sure the issue is the firewall not sending the requests from WAN to the NGINX but I don't know what the issue is. opnsense is pretty much a fresh install, those two port forward rules are the only thing I've added and it automatically added the NAT firewall rules on WAN. The only rules on LAN  are the default rules.

Thanks for the help!