Messages

1

19.7 Legacy Series / No port forwarding for connections from OPNsense itself / fix Nextcloud backup

« on: July 28, 2019, 12:53:43 pm »

I use OPNsense to connect my LAN to the internet using a PPPoE connection to the DSL modem. Inside my LAN I have a Nextcloud server running behind some Let's Encrypt SSL Proxy. OPNsense sets up DynDNS for mydomain.com and port-forwards 80/443 to the Nextcloud Server/SSL-Proxy. So, if I connect o https://mydomain.com/ from a client insinde my LAN or from the outside, connections get translated to Nextcloud by OPNsense just fine.

Problem is that Nextcloud backup does not work this way, because OPNsense also tries to connect to https://mydomain.com/ as well and the port forward rule (interface=WAN, proto=TCP, source=*, destination=nextcloud) is not triggered because the connection does not originate from WAN. However there is no loopback or similar which could be used as the interface to make this work.

Any idea how to fix this? Using the internal LAN IP for the Nextcloud machine won't work because of the SSL proxy which needs the FQDN.

2

18.7 Legacy Series / No DynDNS and IPv6 errors in log after WAN reload

« on: November 13, 2018, 07:09:40 pm »

I run OPNsense 18.7.7 behind a bridged modem and use its DynDNS plugin to keep my WWW domain up to date. This used to work fine until today, where I found that my domain was not accessible. On OPNsense dashboard I found the DynDNS to be displayed in red, so for some reason OPNsense did not managed to update it after getting a new IP on the WAN interface. Running "/usr/local/etc/rc.dyndns" from the console fixed it. I also noticed that the LAN interface did not have an IPv6 address (it is set to track WAN). Pressing "save" and "apply" on the WAN interface fixed that, but it again ended up not having up to date DynDNS.

In the logs I found "Could not resolve host: dyndns.strato.com" as well as "Invalid IPv6 address" (see attached log).

I never got to reproduce the missing IPv6 after a manual WAN reload. The errors still occur on every reload but the LAN ends up having IPv6 and DHCPv6 seems to work just fine. The DynDNS seems to work sometimes, sometimes not.

Looks like timing issues to me. Anyone else seeing anything like this?

3

German - Deutsch / Re: [Siproxd & VOIP Support] Problem- und Lösungsthread

« on: November 04, 2018, 09:03:21 am »

Sieht so aus als wenn Siproxd die CallerID umschreibt. [...]

Danke für die ausführliche Erklärung!

Ich habe gestern noch etwas recherchiert und probiert. Die Plugins habe ich in verschiedenen Kombinationen aus und an geschaltet, halt aber nichts. Im Endeffekt habe ich einen dann einen alten Eintrag im ip-hone-forum gefunden, in dem mit der Zeichenkette 00*;0*49;0*0;00*00 als Suffix ein Workaround beschrieben wurde. Und zumindest in meinen Testfällen funktioniert das.

Ich frage mich jetzt, ob tatsächlich SIPROXD die Nummer abändert oder ob der Effekt nun auftaucht, weil ich in der Fritz!Box nun das "Benutzerdefiniert" Profil statt "Telekom" benutze. Evtl. Hat "Telekom" ja diese oder eine andere Tauschregel eingebraut?

4

German - Deutsch / Re: [Siproxd & VOIP Support] Problem- und Lösungsthread

« on: November 03, 2018, 11:51:06 am »

Dort wird +49xxxx angezeigt... siehe Anhang. Auf der Übersichtsseite wieder nur 49xxxx :/

5

German - Deutsch / Re: [Siproxd & VOIP Support] Problem- und Lösungsthread

« on: November 02, 2018, 07:37:59 am »

>> Tritt dieses Problem denn bei jedem Anruf auf, oder nur partiell.

Es tritt zumindest bei den beiden Mobilnummern (Telekom und O2) auf, mit denen ich es gestern testen konnte. Beide Nummern hatten das Verhalten vor Umstellung auf SIPROXD nicht gezeigt.

>> Und wo taucht das in der FritzBox auf, im Telefonbuch oder auf der Diagnose Seite?

Die Nummern werden so auf den Mobilteilen angezeigt. Dort wird ja normalerweise für bekannte Nummern der hinterlegte Name aus dem Telefonbuch der Fritz!Box angezeigt. Auch auf der Fritz!Box in der Anrufshistorie sieht man die Nummern "falsch" in der Anrufsübersicht auf der Übersichtsseite (siehe Screenshot). Unter Diagnose finde ich nichts passendes, dort habe ich nur die Unterseiten "Funktion" und "Sicherheit"...

6

German - Deutsch / Re: [Siproxd & VOIP Support] Problem- und Lösungsthread

« on: November 01, 2018, 10:06:45 pm »

Erst einmal großen Dank an NicholasRush, deine Bildanleitungen sind super, hat mir sehr geholfen.

Mein Setup: Telekom DSL und VOIP, OPNsense hinter einem DSL-Modem im Bridge-Modus, Fritz!Box 7320 (nur für VoIP) mit zwei Fritz!Fons direkt hinter der OPNsense. Ich kann sowohl raus telefonieren als auch angerufen werden: so weit so gut!

Einziges Problem: eingehende Nummern haben das falsche Format. Statt 049111111 werden die Nummern als 49111111 angezeigt. Telefonieren klappt, man kann aber logischerweise nicht zurück rufen und die Nummern werden auch nicht gegen das hinterlegte Telefonbuch gematcht.

Da die Nummern ohne SIPROXD (static NAT auf der OPNsense box) korrekt durch kamen, gehe ich davon aus, dass hier SIPROXD den Fehler verursacht. Ich finde aber keine passende Option. Hat jemand eine Idee?

7

18.7 Legacy Series / Re: Nextcloud backup not working / Accessing NATed server from OPNsense

« on: October 25, 2018, 09:30:43 pm »

Found the log in System > Log files > General:

config[38352]: {"url":"http:\/\/mydomain.com\/remote.php\/dav\/files\/micmon\/","content_type":"text\/html","http_code":301,"header_size":222,"request_size":184,"filetime":-1,"ssl_verify_result":0,"redirect_count":0,"total_time":0.004059,"namelookup_time":0.002517,"connect_time":0.00322,"pretransfer_time":0.003387,"size_upload":0,"size_download":185,"speed_download":46250,"speed_upload":0,"download_content_length":185,"upload_content_length":-1,"starttransfer_time":0.003954,"redirect_time":0,"redirect_url":"https:\/\/mydomain.com\/remote.php\/dav\/files\/micmon\/","primary_ip":"192.168.178.100","certinfo":[],"primary_port":80,"local_ip":"192.168.178.1","local_port":48586}

The primary_port 80 got me thinking... changed URL from "mydomain.com" to "https://mydomain.com" and now the backup works.

So, if anyone knows a better solution, please let me know!

8

18.7 Legacy Series / Re: Nextcloud backup not working / Accessing NATed server from OPNsense

« on: October 25, 2018, 09:15:01 pm »

Already tried that (using unbound). LAN clients seem to pick up the override just fine. However, OPNsense itself does not seem to use the overrides.

# host mydomain.com    // run from OPNsense
mydomain.com has address 79.x.x.x   // still returns public IP

I then changed System > Settings > General > DNS servers, replaced 1.1.1.1 with 192.168.178.1 (localhost). After that:

# host mydomain.com
mydomain.com has address 192.168.178.100

The output of "curl -v https://mydomain.com" looks fine now. However, the backup still does not work. Any idea where to get a log of the backup function?

9

18.7 Legacy Series / Re: Nextcloud backup not working / Accessing NATed server from OPNsense

« on: October 24, 2018, 10:04:57 pm »

>> can you try to move the web interface to another port?
This won't help.

>> Is NAT-Reflection enabled?
Yes, via the global option "Reflection for port forwards".

10

18.7 Legacy Series / [SOLVED] Nextcloud backup not working / Accessing NATed server from OPNsense

« on: October 24, 2018, 08:34:10 am »

When trying to configure Nextcloud backup I get "communication failure".

My Nextcloud server is located inside my LAN behind the OPNsense appliance, which itself serves as a firewall/router behind a bridged DSL-modem. On OPNsense I have configured dynamic DNS and port forwarding (80, 443). I can reach my Nextcloud server both from the LAN as well as from the outside. However, I cannot reach it from OPNsense itself, so the backup function does not work.

I have tested with "curl -v -k https://mydomain.com": I get the Nextcloud login from any client inside my network as well as from the outside. However I get the OPNsense login when run from OPNsense.

OPNsense resolves the dynamic DNS name of the server which is the public IP on the WAN interface on the OPNsense appliance itself. Now it should trigger the port forwarding, however this does not seem to be the case. I assume this is because "IF" is "WAN" inside my NAT rule and this does not match the connection initialed from OPNsense itself. For the same reason, a second rule with "IF" set to "LAN" won't work.

Any idea how to fix this?