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

#1
Dear all, I've a pretty simple use case but whatever I've tried it did not work.

Situation:
Two server with web-application served on different ports:
server1.domain.internal:8001
server2.domain.internal:8002

My goal is to setup a reverse proxy and serve the applications via different path, e.g

myapps.domain.internal/app1 --> server1.domain.internal:8001
myapps.domain.internal/app2 --> server2.domain.internal:8002


I know the basics about nginx, but even with the easiest application it doesn't work, either pictures are missing, wrong formatting, parts of the page are missing.

Config NGINX:
  • Server: myapps.domain.internal with 2 Location
  • Location1: URLPattern /app1
  • Location2: URLPattern /app2
  • Upstream Server and Upstream are defined

I did some research but no solution works, may someone has an idea, Thanks

 

#2
Hallo, bin jetzt auch Besitzer eines BambuLab A1 Drucker und hab folgendes Setup am Laufen mit dem es funktioniert.

@viragomann
Kann sein das es ein Update gegeben hat im Bambu Studio und es funktioniert jetzt.

Mein Setup:
Zwei Netze: IoT (Bambu), Kids (dort ist der PC mit der Bambu Software), beider per WLAN Verbunden (TP-Link Omada)

Schritt 1: UDP Broadcast konfigurieren
  • Interfaces: IoT, Kids
  • Mulitcast Addresses: 239.255.255.250
  • Source Address: 1.1.1.1
  • Listen Port: 1990

Schritt 2: Firewall Regel IoT (nachdem der Broadcast zwischen den Netzen konfiguriert ist benötigt es eine Regel die den Traffic aus dem IoT Netz gestattet.
  • Interfaces: IoT
  • TCP/IP Version: IpV4
  • Protocol: UDP
  • Source: #Printer IP#
  • Destination: 239.255.255.250
  • Destination port range: 1990 - 1990

Schritt 3: Jetzt funktioniert der Broadcast und die Software kann den Drucker "discovern". Damit die Verbindung funktioniert benötigt es noch eine Regel welche den Verkehr zwischen Software (PC) und dem Drucker gestattet.

  • Interfaces: Kids
  • TCP/IP Version: IpV4
  • Protocol: Any
  • Source: Kids Net / oder PC IP
  • Destination: #Printer IP#
  • Destination port range: Any

Die Software läuft auf einer Windows 11 Kiste, es benötigt auch dort eine Firwall Regel welche Broadcasts auf Port 1990 entgegen nimmt.

Vielleicht hilt das dem einen oder anderen beim Setup des Weihnachtsgeschenks

Freundliche Grüße
#3
German - Deutsch / Re: access logfile für Wireguard
March 03, 2025, 07:34:26 AM
Hallo,

Würde mich auch interessieren wo sich das Log befindet, speziell die Authentication Logs um ein Monitoring darauf aufzubauen.

Gibt es dazu etwas?
Vielen Dank für eure Hilfe.

Lg
#4
Hi,

I've analyzed the issue today and it was not related to OpnSense.

The NTP daemon on my Admin Workstation stopped for what ever reasons and due to that the time was out of sync.

br
#5
Hi,
I've discovered the same issue today.

Will look at it tomorrow and provide an update.

br
#6
Hi,
thanks for the interesting post.

You mentioned
QuoteOpnSense settings here are somewhat "wrong".
. In my case on the WAN Interface PPPoE (without VLAN), the calculated PPP MTU is according to the GUI 1492 (see MTU1.png).
I've tried your script which returns 1492 too, so it seems to match, however if I enter the 1492 as fixed value in the GUI, the calculated value is set to 1484 (see MTU2.png).
Question, what is the correct configuration? Keep the calculated value or set it to the 1492?

Thanks

#7
Hi,

I already mentioned the issue here https://forum.opnsense.org/index.php?topic=36688.

Now I migrated to a new hardware with fresh install and the most recent version of opnsense but the issue still exists, so I started this thread.

Any help, hints, ... highly appreciated.

Thanks
#8
Hi,

yes they are.

After pushing the "Save" button (without changing anything) within the settings of the gateway (System: Gateways: Single) it works.

br
#9
Hi all,

I face a strange issue since a couple of month.
Now I did a clean installl on new hardware (import of config) but the issue still exists.

After every reboot (and sometimes after a couple of weeks) the gateway goes offline and therefore internet connectivity is lost. All local systems etc. are running without any issue when this issue happens.

Gateway (System: Gateways: Single) is up and running and also within System: Routes: Status the default route is listed.

What I do to solve the issue until the next reboot (or when the issue occurs) is to hit the "Save" (may than the config is re-applied) button within the settings of the gateway (System: Gateways: Single).
Seconds after that internet connectivity is back.

Any idea how to solve or analyze the issue, I found some similar posts from the past but no solution.
Beside that everything works fine.

br
#10
Dear all,

may some of you are facing the same or an similar issue.

After every reboot (and sometimes after a couple of weeks) it seems the route for default gateway is lost and therefore internet connectivity is lost. All local systems etc. are running without any issue when this problem happens.

OPNsense 23.7.11-amd64 (issue occurs since ~23.7.9 )
FreeBSD 13.2-RELEASE-p7
OpenSSL 1.1.1w

Gateway (System: Gateways: Single) is up and running and also within System: Routes: Status the default route is listed.

What I do to solve the issue until the next reboot (or when the issue occurs) is to push the "Save" (may than the config is re-applied) button within the settings of the gateway (System: Gateways: Single).

Any idea how to solve or analyse the issue, beside that everything works fine.

br
#11
Hi

Sounds pretty similar to my issue. After every reboot I've to configure "something" on the gateway to bring Internet connectivity back.

Br
#12
Dear all,

just for your information,

applying # opnsense-revert opnsense && opnsense-patch 0adf8a2bb didn't work for me.


Only with # opnsense-patch a40dd50aec6 I could restart DHCPv6 and radvd again.

br
#13
Hi franco.

May I explain it a bit more in detail:

Before update:

  • 2 Gateways configured (1xPPPoE, 1xIPv6 Tunnel)
  • 1 Gateway enabled (PPPoE) and active
  • Upstream gateway - disabled (was never enabled since years)
  • Disable Gateway Monitoring - enabled
  • IPv6 Gateway disabled

After update:

  • No internet access possible. Initially I thought it is an unbound issue with external name resolution, but when I tried to PING external IP on the sense I got
  • "No route to host" message", which points me to the a possible issue with the default route.
  • no "default route" after update
  • after checking "Upstream Gateway" route was added and it worked again

After next reboot I had to disable "Upstream Gateway"

br


#15
Dear all,

may you are interested in.

I faced the same issue "No internet connection" after update.

Even though I've only one gateway I had to check the "Upstream Gateway" checkbox, afterwards everything worked again.
Next issue I had was during the next reboot. Again the same issue and I had to "uncheck and check" the same checkbox again to make it work again.

br