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 - Ronny1978

#1
Hello @virgomann.

Thanks for your post and try to helping me.

QuoteDid you enable the X-Forwarded-For header in the advanced settings?
-> yes, see me screenshot Caddy.jpg



QuoteDo you proxying the whole domain or a virtual directory?
-> Domain

QuoteIs Caddy using the same protocol (http / https) as HAproxy to access the backend?
-> see my pictures HAProxy.jpg, Caddy2.jpg and Caddy3.jpg

Thanks a lot.

Ronny
#2
Thank for your reply and your hint. Unfortunately it doesn't help to solve the problem and understanding caddy. 😉 I have same family members, which also use my Synology and it is to difficult to solve problems (VPN) remote and for these members it is easier to realize the access over a reverse proxy with a Yubikey. Many thanks again.

Ronny
#3
Hallo zusammen.

Ich habe eine Frage, bei der ich einfach nicht weiterkomme. Zunächst einmal der Hintergrund:

- OpenSense 26.1.5
- Let's Encrypt-Zertifikat über die Netcup-API (*.mydomain.de) unter Verwendung des ACME-Clients
- Caddy-Plugin 2.1.0
- Synology DSM 7.2.2 Update 8
- Yubikey als Hardware-Sicherheitsschlüssel
- Bisherige Nutzung -> HAProxy -> Die Anmeldung bei DSM funktioniert sowohl internen als auch mit dem Yubikey
- Umleitungen meiner Server/Anwendungen in Unbound auf die IP-Adresse der Firewall (192.168.100.1)

Ich wollte am Wochenende meinen Reverse-Proxy von HAProxy auf Caddy umstellen. Zunächst funktionierte alles einwandfrei. Dann stellte ich gestern fest, dass die Anmeldung bei Synology DSM (Benutzername/Passwort/Yubikey als Sicherheitsschlüssel) nicht mehr funktioniert. Die Anmeldung wird ,,unterbrochen" – aber nicht vollständig. Das bedeutet, dass DSM sie als fehlerhafte Anmeldung registriert. Nach drei Versuchen hatte ich mich ausgesperrt. Ich konnte mich dann über ein VPN und den OTP-Code (über den Yubikey) wieder entsperren. Anschließend habe ich den Yubikey aus den Einstellungen entfernt und versucht, ihn neu zu koppeln -> Fehlermeldung: ,,Die Registrierung konnte nicht abgeschlossen werden. Bitte versuchen Sie es erneut".

Nach einer Stunde hatte mich die Suche bei Google und hier im Forum nicht weitergebracht, und selbst die KI konnte nicht helfen. Die Theorie lautet, dass Caddy etwas mit den Headern macht, was HAProxy nicht tut. Ich wechselte zurück zu HAProxy, und sofort wurde der Yubikey wieder als Sicherheitsschlüssel registriert, und ich konnte mich erneut mit dem Yubikey anmelden.

Der Grund für meinen Wechsel zu Caddy war, dass ich in Zukunft gerne Authelia oder Authentik nutzen möchte. Ja, das ist auch über Lua-Skripte in HAProxy möglich, aber leider verstehe ich die technischen Details nicht gut genug, um wirklich zu begreifen, was ich da eigentlich mache.

Ich hoffe, dass mir hier im Forum jemand weiterhelfen kann, da ich weiß, dass es hier viele Mitglieder mit reichlich technischer Erfahrung und Wissen gibt.

Vielen Dank im Voraus für eure Hilfe. 😉
#4
Hello Together.

I have a question I can't seem to figure out. First of all, the background:

- OpnSense 26.1.5
- Lets Encrypt Cert with API of Netcup (*.mydomain.de) with ACME Client
- Caddy Plugin 2.1.0
- Synology DSM 7.2.2 Update 8
- Yubikey as Hardware-Security-Key
- usage until yet -> HAProxy -> Login in DSM works with Yubikey internal and external
- Rewrites of my Servers/Application in Unbound to IP of the Firewall (192.168.100.1)

I wanted to switch my reverse proxy from HAProxy to Caddy over the weekend. It worked fine at first. Then yesterday I noticed that logging in to Synology DSM (username/password/Yubikey as a security key) no longer works. The login is 'interrupted' – but not completely. This means that DSM registers it as an incorrect login. After three attempts, I locked myself out. I was then able to unlock it using a VPN and the OTP code (via the Yubikey). I then removed the Yubikey from the settings and tried to re-pair it -> error message: 'Registration could not be completed. Please try again'.

After an hour, searching on Google and here in the forum hadn't got me anywhere, and even the AI couldn't help. The theory is that Caddy does something with the headers that HAProxy doesn't. I switched back to HAProxy, and immediately the Yubikey registered as a security key again, and I was able to log in using the Yubikey once more.

My reason for switching to Caddy was that I'd like to use Authelia or Authentik in the future. Yes, that's also possible via Lua scripts in HAProxy, but unfortunately I don't understand the technical details well enough to really grasp what I'm doing there.

I'm hoping that someone here in the forum can help me out, as I know there are plenty of members here with loads of technical experience and knowledge.

Thanks in advance for your help. 😉
#5
Super 😉👍. Vielen Dank für den Tipp. Jetzt läuft es mit NAT Typ 2. Dann sind wohl auch bei der XBox eigentlich die Portweiterleitungsregeln nicht erforderlich?

Nochmals vielen, vielen Dank und ein wunderschönes und gesundes Wochenende.
#6
German - Deutsch / Re: XBox + PS5 NAT Typ
June 12, 2025, 03:29:19 PM
Hallo Jens,

ich bin im Stress noch gar nicht dazu gekommen mich für deine Unterstützung zu bedanken. Ich habe das Outbound NAT so wie angehangen eingestellt. Portweiterleitung und WAN Regel, sind entgegen der Einstellung der XBOX deaktiviert. Dennoch habe ich nur Typ 3 auf der Playstation. Irgendwas mache ich noch falsch.

Hast du noch einen Tipp für mich?

P.S. Würde es etwas bringen mit meinem eigenen VLAN zu arbeiten (für die Konsolen) und dann dort mit UPNP?

#7
General Discussion / XBox + PS5 NAT Typ
June 08, 2025, 04:27:08 PM
Hello everyone,

I hope you can help me. First of all:

- I am on version 25.1.6_4
- UPNP as a plugin is not installed
- NAT outgoing and NAT port forwarding for the XBox (192.168.10.2) in VLAN IoT is set up and works -> NAT type on the XBox is OPEN

Now my son has got a PS5. We have also set up a fixed IP (192.168.10.16) in the VLAN IoT and the NAT type is set to 3 (which would be STRICT for an XBox). So I set up the alias ports for the PS5 (UDP 3478:3480 & 49152:65535 // TCP 80, 443, 1935, 3074, 3478:3480) and cloned the NAT rules, i.e. port forwarding and output.

Unfortunately, the NAT remains on type 3. Since Xbox and PS5 use some of the same ports, I could imagine that this could cause problems with port forwarding.

How do I get to NAT type 1 or 2 on the PS5?

Thanks for your help.

Ronny
#8
Hallo Zusammen,

ich hoffe, ihr könnt mir helfen. Vorab:

- ich bin auf Version 25.1.6_4
- UPNP als Plugin ist nicht installiert
- NAT ausgehend und NAT Portweiterleitung für die XBox (192.168.10.2) im VLAN IoT ist eingerichtet und funktioniert -> NAT Typ auf der XBox ist OPEN

Nun hat mein Sohn eine PS5 bekommen. Wir haben hier auch eine feste IP (192.168.10.16) im VLAN IoT eingerichtet und der NAT Typ steht auf 3 (was bei einer XBox STRICT entsprechend würde. Also hat ich die Alias Ports für die PS5 eingerichtet (UDP 3478:3480 & 49152:65535 // TCP 80, 443, 1935, 3074, 3478:3480) und die NAT Regeln, also Portweiterleitung und Ausgang geklont.

Leider bleibt der NAT auf Typ 3 stehen. Da ja XBox und PS5 teilweise die gleichen Ports nutzen, könnte ich mir vorstellen, dass das bei der Portweiterleitung Schwierigkeiten geben könnte.

Wir komme ich bei der PS5 auf NAT Typ 1 oder 2?

Danke für eure Hilfe.

Ronny
#9
Es scheint zu funktionieren. Ich hatte bis jetzt keine Probleme mehr. Warum das beim ersten Neustart nicht gleich angezeigt wurde, kann ich allerdings nicht sagen.
#10
Im Moment scheint es wieder zu funktionieren. Nach eine Stunde war die IP dann zu sehen. Ich dachte, dass er sofort die IP an IPv64 weitergibt, sobald die OpnSense neu startet. Weitergeben scheint sie IP aber zu haben. Nur angezeigt wird sie nicht gleich, warum auch immer.

Ich würde das mal noch eine Woche beobachten und dann den Thread als GELÖST setzen sollte es weiterhin funktionieren.
#11
Hallo Zusammen,

ich habe heute früh das OpSense Update auf 24.7.4 gemacht. Seitdem habe ich Probleme mit dem ddclient und IPv64.net. Kannst jemand bestätigen, dass es am Update von OpnSense liegt?

2024-09-14T07:09:35 Notice ddclient WARNING: Could not determine an IP for xxxxx.ipv64.net

Ich hatte mich dann bei IPv64 eingeloggt und gesehen, dass dort irgendwo ein Update angekommen ist. Mir fällt es jetzt schwer zu sagen, ob es nun an OpnSense oder IPv64 liegt. Kann mir jemand helfen?

OpnSense Version 24.7.4_1
os-ddclient Version 1.24

Danke für eure Mühe und Rückmeldung und noch ein wunderschönes und gesundes Wochenende.  :)
#12
Thank you Monviech. I looked a little more intensiv in the crash report. It is a PHP error, which is diccussed on GitHub. Some line should be changed manuelly. I think I waiting for the fix of acme plugin.

Have a nice weekend.

Ronny
#13
Hello julssark.

Thank you for your support. I use another port for DSM and at activation of the automation I got a crash report in Opnsense.  :-\
#14
Hello julsssark.

Can you give me some hints for a working configuration? I got a crash in Opnsense, when I run the automation. I also use the "Upload certificate to Synology DSM action".

Do ypu have also a special port for https (not 5001)?
What version of DSM du you have?
What version of Opnsense oder ACME Plugin?
Update: Is it possible to run ONLY automation or works it only in combination of update certificate?

Thanks a lot for helping me.  ;)

Ronny
#15
I also have the same problem. For me, the plugin causes a crash, both when deploying the LE certificate to DSM and to Proxmox.

@julsssark: But the post is from December 2023 ::) I still hope that the problem will be fixed. Because automation would be a wonderful thing so that you don't have to worry about the LE certificate in all hosts.