Messages

1

Virtual private networks / Re: Not seeing my LAN devices when using OpenVPN

« on: September 08, 2023, 12:22:57 pm »

What do you mean with "cannot see"?
Are they not reachable / pingable?

When using tools like some network scanners or something, it is possible that those tools will not check VPN / LAN networks, staying in the local network only.

2

German - Deutsch / Re: IPv6 Port Weiterleitung mit OpnSense

« on: September 02, 2023, 01:59:22 pm »

Es soll also echt der gesamte Adressbereich an die VM geleitet werden?
Keine Ahnung wie man das macht, aber ich sehe auch keinen wirklichen praktischen Grund dafür 

3

German - Deutsch / Re: IPv6 Port Weiterleitung mit OpnSense

« on: September 02, 2023, 01:42:51 pm »

... daher auch nicht Portweiterleitung, sondern Portfreigabe.
Das ist ua der Vorteil von v6: kein NAT = keine Weiterleitung weil das Gerät direkt über seine GUA erreichbar ist. Der Zugriff nuss nur in der Sense und ggf auf dem Gerät selbst erlaubt werden.

4

23.7 Production Series / Re: os-wireguard 2.0[2]

« on: August 31, 2023, 11:45:14 am »

That's the reference in release notes to provided external sources, eg github

5

23.7 Production Series / Re: bectl export command

« on: August 26, 2023, 09:51:30 pm »

I am using bemanager for this: https://github.com/JRGTH/bemanager

Works fine and is easy to use.

6

German - Deutsch / Re: SUB-Domain für Router und NAS über DynDNS

« on: August 26, 2023, 09:32:21 am »

Unklar was du mit "teilen des links" meinst, aber falls du damit den quick connect Dienst meinst, dann nochmal:
Das ist nicht mit der Erreichbarkeit über Portfreigaben / Weiterleitungen zu vergleichen. Natürlich nehmen NAS und Client hier irgendwelche Ports um sich mit dem Syno Server zu verbinden.
Bei Zugriff über Portweiterleitung wird nur ein Port benötigt und zwar der, auf dem dsr Dienst lauscht und das wird mit hoher Wahrscheinlichkeit per default 8080 oder 443 sein. Dieser eine Port muss dann weitergeleitet werden, aber welcher das ist können wir nur raten. Du musst also schauen welcher Port für diesen Dienst eingestellt ist und diesen an das NAS weiterleiten.

7

German - Deutsch / Re: SUB-Domain für Router und NAS über DynDNS

« on: August 25, 2023, 05:54:21 pm »

Weil quick connect halt keine eingehende Verbindung erfordert. Server und Client melden sich bei einem Syno Server und bauen so die Verbindung auf:
https://kb.synology.com/de-de/DSM/help/DSM/AdminCenter/connection_quickconnect?version=7
Das hat nichts damit zu tun, was Du (vermutlich) vor hast!

Willst Du diesen Dienst partout nicht nutzen?
Oder willst Du nur, dass die Fotodienste über deine eigene Domain erreichbar sind? Dann setze die Domain doch einfach auf den quick connect Link und fertig... damit setzt Du Dein NAS auch nicht dem Internet aus (wobei fraglich bleibt wie sicher solche Dienste wie quick connect wirklich sind).

8

23.7 Production Series / Re: 23.7.2 - Monit repeatedly emailing about Interface Down (backup WAN)

« on: August 25, 2023, 04:50:54 pm »

Have you set a reminder in alert settings?
Refer to https://docs.opnsense.org/manual/monit.html Alert Settings

9

German - Deutsch / Re: SUB-Domain für Router und NAS über DynDNS

« on: August 23, 2023, 10:08:19 pm »

Ich kenne Syno und den Dienst nicht, nehme aber an, dass für diesen Dienst über einen externern Server von Syno kommuniziert bzw. die Verbindung hergestellt wird (NAS und Client melden sich beim Server und bauen darüber die Verbindung auf, ohne Portfreigabe, etc.).
Absicherung durch eine Firewall (egal ob Sense oder auf der Syno) macht in jedem Fall Sinn, so kann man wenigstens die Adressbereiche einschränken, zB auf Europa oder wie man es eben braucht.

Du wirst hierbei eher ein Problem der Portfreigabe haben. Du musst ja den benötigten / verwendeten Port (zB 8080) an das NAS weiterleiten. Von welchen Ports die Verbindungen aufgebaut werden ist relativ egal, du leitest ja den Port weiter, auf dem der Dienst läuft...

10

German - Deutsch / Re: SUB-Domain für Router und NAS über DynDNS

« on: August 23, 2023, 09:48:38 pm »

Mal ganz doof gefragt:
Wenn du ein VPN Server auf der Sense hast, wozu dann noch die Syno dem Internet aussetzen?
Für Filesharing mit Dritten ohne VPN Zugang würde ich mir auch bei Syno was anderes einfallen lassen...

11

General Discussion / Re: Alerting without emails?

« on: August 23, 2023, 06:29:34 pm »

Emails can be received on smartphones
I think you are talking about something like push messages to a special app... This is what I would consider as everything else but enterprise. For enterprise environments you are good to go with SNMP.

However, using Email as method is fine for me since I have special receiver addresses for alert and warning/info mails, each with a unique sound on the smartphone...

12

23.1 Legacy Series / Re: ddclient doesn't support multi-wan ip update

« on: August 22, 2023, 10:18:20 pm »

That's interesting, I never came to the idea to try that. However, as I described works fine for me.

13

23.1 Legacy Series / Re: ddclient doesn't support multi-wan ip update

« on: August 22, 2023, 08:00:09 am »

But as soon as I enable both DDNS entries, no IP address update happens.

This may be another issue. I had some troubles when I changed backend and I had to add all services from scratch after change.

For the firewall rule, I'm not sure what the gateway settings "set gateway to secondary WAN / GW to monitor" mean.

See first screenshot, column "Gateway". This is to be configured in the rule on the bottom of the page (right above advanced options). With this, you set that traffic for IP check will always be redirected to this gateway when it tries to leave from primary / wrong gateway.

As I understand it, the rule is supposed to block the connection on the primary WAN interface.

Yes, but it is more likely a redirection to the desired gateway.

Does this mean that the DDNS update for secondary WAN fails as long as the primary gateway is active

No. This rules is intended to always use secondary gateway, even if first gateway is online / active.
Without that rule DDNS update also should not fail, but always use the avtive gateway (as desribed in B) ).

14

23.1 Legacy Series / Re: ddclient doesn't support multi-wan ip update

« on: August 22, 2023, 07:40:43 am »

Now some explanations about the last screenshot:

1a marked entries are those routed over secondary WAN via created rule described in A).

3a marked entries are those for primary WAN using "Interface IPv6". Those v6 addresses are issued directly on OPNsense WAN interface, so there is no need for external check IP services.

2a marked entry is just a test (since 1st WAN is CGNAT there is no usable public IPv4).
This one will use the active gateway since chosen check IP method (nsupdate) is not part of the alias shown in first screenshot. This one is what is described in B).

15

23.1 Legacy Series / Re: ddclient doesn't support multi-wan ip update

« on: August 22, 2023, 07:32:35 am »

Here we go... this is what I already wrote for the docs (since I am not familar with github, I am not able to provide it there). I also added some screenshots (please note that the description is not based on the screenshots):

Multi-WAN
In multi-WAN environments you would like to update your domain with primary WAN’s IP address even if other WAN interfaces are available, or separately for each WAN. You will be quite fine, if your desired IP address is issued directly on your OPNSense’s interface, but not if you have upstream router or modem connected to your sense.
In the latter case ddclient might check the IP address on the wrong interface, resulting in wrong IP address issued to your domain.

The following describes different secenarios and how to deal with it in multi-WAN environments to make sure that the desired IP address will be issued to your domain.

IP addresse(s) directly issued on your OPNsense interface
If the desired IP address for an interface is issued directly on your OPNsense, you are fine using „Interface IPvX“ as check IP method in ddclient. For those interfaces there is no need for further configuration, as long as you are using separate domains for each interface.

Note:
This will always grab the IP address from the chosen interface. This is not suitable if you want to achieve, that the IP address of the actual active WAN will be issued to one and the same domain.

Upstream router / modem connected to OPNsense
For interfaces with upstream devices you usally want to issue your upstream device’s public IP to your domain (but usually not for IPv6). In this case the check IP method „Interface IPvX“ mentioned above may not give you the desired public IP address and you need to choose one of the other methods. All those other methods will use external services to check the public IP address, but, as mentioned at the beginning, ddclient may use the wrong interface to perform its IP checks.

Depending on what is to be achieved you need one of the following configurations:

A) Seperate domains for each interface
1.   Set up DDNS for WAN 1 as desired.
2.   Set up DDNS for WAN 2 and make sure to choose another check IP service (e.g. nsupdate.info) than used 
        for primary WAN.
        If there are more WAN interfaces, choose different check IP services for each.
3.   At Firewall/Alias create an alias as follows:

Enabled = checked
Name =  Check IP WAN 2 (or anything suitable)
Type = Host(s)
Content = URL from IP check service configured for WAN 2 (in this example nsupdate.info). Please see notes below.

4.    Create a firewall rule on WAN 1 as follows:
Action = Pass
Direction = out
Destination = the new created alias for this interface
TCP/IP Version = depending on your needs; in doubt v4+v6 will be fine
Description = Route check IP WAN 2 (or anything suitable)
Gateway = WAN 2

Note:
For alias content do not add the check IP service as it is specified in ddclient, as this is only the service’s name. You need to determine the domain for this service. E.g.
dyndns = checkip.dyndns.org
nsupdate.info-ipv4 = ipv4.nsupdate.info
nsupdate.info-ipv6 = ipv6.nsupdate.info
ip4only.me = ip4only.me, ip4.me (add both to alias)
ip6only.me = ip6only.me, ip6.me (add both to alias)

Note:
If there are more WAN interfaces, you need to create this rule on all WAN interfaces, except the interface to monitor. In such cases you are good to go using floating rules.
Also remember that in this case there are further rules, following the same scheme, for each gateway to monitor required.



Requests to the desired check IP service(s) will now be routed over the given gateway in the firewall rule, resulting in getting the public IP address of the upstream device.


Tip:
For IPv6 you should use „Interface IPv6“ as IP check method in ddclient, as long as you are not intended to update a single domain for the actual active interface.


B) Single domain for actual active interface
Without routing IP checks to a certain gateway as previously described under A), ddclient will always use the active gateway (online with highest priority and marked as „upstream“), even if you have set up policy based routing for your LAN and other subnets.
To make sure ddclient uses the desired gateway, the gateway priority at System/Gateways/Single should match the tiers configured at System/Gateways/Group.

Note:
A lower value means a higher priority.
Gateways marked as „upstream“ will always be used favor to those that are not. To just go by priority, mark all involved gateways as upstream.

In this scenario you have to use any IP check method in ddclient but „Interface IPvX“.

Requests to the check IP service will now be routed over the active gateway, resulting in getting the public IP address of the corresponding upstream device.

Tip:
For sure, the different scenarios can be combined, e.g. having separate domains for WAN 1 and WAN 2 and one domain for the active one. Make sure you are using different IP check services for each, as long as you are not using „Interface IPvX“ method for WAN 1 and WAN 2.