OPNsense
  • Home
  • Help
  • Search
  • Login
  • Register

  • OPNsense Forum »
  • Profile of tiermutter »
  • Show Posts »
  • Messages
  • Profile Info
    • Summary
    • Show Stats
    • Show Posts...
      • Messages
      • Topics
      • Attachments

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.

  • Messages
  • Topics
  • Attachments

Messages - tiermutter

Pages: 1 [2] 3 4 ... 49
16
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.



17
23.1 Legacy Series / Re: ddclient doesn't support multi-wan ip update
« on: August 21, 2023, 09:50:36 pm »
Hi there, I'll answer tomorrow, maybe with kinda tutorial and screenshots provided.

18
German - Deutsch / Re: WAN Failover mittels LTE-Router/Modul
« on: August 21, 2023, 01:44:18 pm »
Unter System: Settings: Administration stellst Du ja ein, auf welchen Interfaces die GUI und SSH grundsätzlich erreichbar ist.
Dann braucht es nur noch eine entsprechende Regel auf dem Interface, die das auch erlaubt. Beim LAN wird diese durch anti-lockout automatisch gesetzt (wenn nicht deaktiviert), für andere Interfaces erstellst Du die Regel halt selbst. Wenn Du das dann noch auf bestimmte IP oder MAC (über einen Alias) begrenzt (wie schon geschrieben), dann hast Du noch mehr Sicherheit.
Ist halt die Frage, wie sehr Du dem lagg0 vertraust.

Aber igc3 scheint dann ja alles andere als ein Fallback zu sein, bislang ist es ja eher das einzige Interface, über das der Zugriff möglich ist.

Anders gefragt: Wie willst Du den Zugriff zukünftig ermöglichen? Wo befindet sich der/die Rechner die Zugriff haben sollen? Soll / muss der Zugriff auf diese beschränkt sein oder darf der Zugriff aus dem gesamten Subnetz möglich sein?

19
German - Deutsch / Re: WAN Failover mittels LTE-Router/Modul
« on: August 21, 2023, 10:48:30 am »
Moin,

ich verstehe die Problematik / Fragestellung nicht so recht.

Über igc1-2 (LAN) hast Du doch Zugang zur Sense, oder nicht, und igc3 dient nur als Fallback?
LAN hat ja schon das Netz 192.168.0.0, so wie Du es haben willst und es würde nur das Fallback entfallen.
Oder ist igc3 eigentlich kein Fallback sondern das Management Interface? Das ließe sich ja auch über ein VLAN auf dem LAN realisieren.

Ich würde halt einfach LTE an igc3 dranhängen, das Netz könnte dabei so bleiben.
Wenn das Modem nicht nur ein Modem ist, sondern auch eine Firewall bietet, könntest Du die GUI ja auch weiterhin auf igc3 als Fallback erreichbar machen. Für mehr Sicherheit könntest Du auch eine Regel erstellen, die hier nur Zugriff von einer bestimmten IP erlaubt. Im Ernstfall / Failover hängst Du halt einen Rechner an igc3 mit der IP die freigegeben ist.

20
23.1 Legacy Series / Re: ddclient doesn't support multi-wan ip update
« on: August 18, 2023, 08:53:11 pm »
I am not really sure if the values was consistend, but I think I would have them double checked. I cannot remember any differences...

21
German - Deutsch / Re: zweite Internetleitung
« on: August 10, 2023, 11:26:16 am »
Anbei ein Screenshot. An den Routen für die Monitor IPs ändert sich nichts, egal ob das entsprechende gateway up oder down ist...

22
German - Deutsch / Re: zweite Internetleitung
« on: August 09, 2023, 11:34:34 am »
Wenn eine Monitor IP eingetragen ist, dann wird diese doch fix für das entsprechende Gateway im routing table verankert, sodass diese IP ausschließlich über das entsprechende gateway erreicht werden kann...

23
German - Deutsch / Re: zweite Internetleitung
« on: August 09, 2023, 09:50:40 am »
Warum im Netz des Anbieters? Das kann auch jede öffentlich erreichbare IP sein. Das ist sogar zu bevorzugen, denn wenn beim ISP etwas ausfällt, die gewählte Monitor IP aber weiterhin erreichbar ist, dann hat man nichts gewonnen...

24
Virtual private networks / Re: Wireguard-go VS Wireguard-kernel plugin
« on: August 07, 2023, 11:16:49 am »
Since I have configured PersistentKeepalive = 25 on Windows the problem did not occur again...
But as said, I am not sure if the problem occured since I changed to kmod.

However, I will stay with this setting :)

25
23.1 Legacy Series / Re: ddclient doesn't support multi-wan ip update
« on: August 03, 2023, 09:22:46 am »
Thank you... for sure I like to contribute.

I will start over creating a .doc file, including the option to update the active interface's IP instead of both / all separated.

26
23.7 Production Series / Re: New DynDNS-Plugin no longer supports "Interface to monitor" "WAN Failover"
« on: August 02, 2023, 11:27:52 pm »
Have a look at this:
https://forum.opnsense.org/index.php?topic=34139.msg169680#msg169680

27
Virtual private networks / Re: Wireguard-go VS Wireguard-kernel plugin
« on: August 02, 2023, 08:40:36 am »
Using wg kmod for a longer time now, I have no such issues on Android devices, keepalive is not configured.

But I have a similiar issue on Windows. However, I cannot say if this is since kmod and the problem only occurs when connection is established on WAN IPv6, not when established on LTE IPv4. I assume this is a v6 connectivity issue on client side as connection then cannot be re-established for a while, but I will give it a try with setting keepalive.

28
23.7 Production Series / Re: Upgraded to 23.7. Wow.
« on: July 31, 2023, 05:20:57 pm »
Already heard from a friend that everything on both HA devices went fine.
However and as always I will wait few days and more until I'll go ahead.

Looking forward to more positive experiences...  :)

29
German - Deutsch / Re: Zwei NordVPN Zugänge nur für spezifische VLANs einrichten
« on: July 31, 2023, 07:22:55 am »
Bei mir läuft AGH auf der Sense und lauscht somit auf allen Interfaces, daher brauche ich keine entsprechende Weitereleitung.
In Deinem Konstrukt, sofern ich es richtig überblicke, brauchst Du später eine Regel vor der Regel, die alles aus dem VLAN an das VPN Gateway routet, die die DNS Anfragen an AGH routet, sofern gewünscht ist, dass AGH das macht.

Das Problem was Du hast ist ja aber schon viel früher angesiedelt. Der Name um die VPN Verbindung herstellen zu können muss für die Sense aufgelöst werden, da hat weder das VLAN noch das VPN selbst etwas mit zu tun. Die Sense erreicht offensichtlich Dein AGH nicht und kann daher keine Namen auflösen, das dürfte dann aber immer und für alle Anfragen zutreffen, nach dem was Du jetzt geschrieben hast, funktioniert das aber?!?!
Die Sense muss auch gar nicht zwingend AGH für DNS nehmen, hast Du unter System/Settings/General denn DNS Server angegeben? Diese würde die Sense dann selbst für die Auflösung verwenden, damit wird dann auch die Adresse für den VPN Verbindungsaufbau aufgelöst, alle anderen Geräte können dann ja immer noch an AGH geleitet werden.

30
German - Deutsch / Re: Zwei NordVPN Zugänge nur für spezifische VLANs einrichten
« on: July 29, 2023, 03:21:58 pm »
Und funktioniert ansonsten die Auflösung mit AGH? Klingt eher nach einem Problem fernab vom VPN...

Pages: 1 [2] 3 4 ... 49
OPNsense is an OSS project © Deciso B.V. 2015 - 2023 All rights reserved
  • SMF 2.0.19 | SMF © 2021, Simple Machines
    Privacy Policy
    | XHTML | RSS | WAP2