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

#1
German - Deutsch / Re: von 23.7 direkt auf 25.1
February 26, 2025, 06:51:49 PM
Ich habe ein ähnliches Problem, von der 23.7 weg zu kommen.
4 Standorte per ipsec verbunden
A--B / A--C / A--D / C--D
nach einem Update von A auf 24.1 waren alle Tunnel A--X tot und ließen sich nicht in überschaubarer Zeit wieder beleben.
Auch nach einer 24.1 Neuinstallation mit Restore blieben die Tunnel offline.
Also A zurück auf 23.7 mit Restore, alles wieder im grünen Bereich.
Frühere Updates seit 20.x hatten da nie Probleme.

Was wäre denn da ein zuverlässiges Szenario?

Alle Standorte mit 25.x neu installieren mit anschließendem Restore der 23.7 Konfiguration?
#2
Hello,
all my IPsec tunnels are down in phase 2 and two in phase 1
Under status i have an unnamend  tunnel

#3
Hallo,

wir haben das Problem, daß eine der beide Phasen 2 einer IPv4 (IKEv2) hin und wieder die Verbindung verliert, die Phase 1 aber verbunden bleibt.
(Die Gegenstelle ist eine Cisco Box und deren Spport ist, sagen wir mal "großartig und supertoll")

Daher haben wir unter Monit einen Check eingerichtet, der den Verbindungsabruch erkennt.
Leider lässt sich die Verbindung aber nicht beenden und neu verbinden.

2024-01-29T12:05:13   Error   monit   'RZ-Wartung-con3-Restart' failed to stop (exit status -1) -- Program '/usr/local/sbin/swanctl --terminate --ike con3' timed out after 30 s   
2024-01-29T12:04:40   Error   monit   'RZ-Wartung-con3-Restart' ping test failed
2024-01-29T12:04:40   Error   monit   Ping response for 172.30.130.130 1/1 timed out -- no response within 5 s


Über die Webgui kann man den Tunnel in der Status Übersicht unter Phase 1 "[ x ] disconnect" auch nicht beenden.
Über ein [ restart service ] oben rechts, wird der tunnel beendet und neu gestartet.
Davon sind aber dann auch noch 4 andere tunnel betroffen, die ohne Probleme laufen und eigentlich nicht unterbrochen werden sollten.

Bug or Feature?
#4
Ist nur eine vorübergehende Lösung, die Lancom wird im Februar durch eine andere Leitung (anderes Gerät)  ersetzt, dann steht eine direkt IP zur Verfügung.
#5
Hallo,

Danke für die Info.

Ich habe auf der Lancom Internetseite eine Konfiguration über zwischengeschaltete Router gefunden.

Ich müsste wie dort beschrieben beide Opnsense mit NAT-T konfigurieren.

Dort im 3. Beispiel wäre meine B die (2) und meine A die (4)
Müsste dann auf der (3) Lancom ein NAT x.x.x.1 zur 10.1.1.2 einrichten.

Bei der LanCom gibt es eine einfache Einstellung
  • (x) Nat Transversal aktiviert.
    Entsprechendes gibt es auch in der OPNsense unter IPsec P1 : NAT Traversal = enabled.
    Set this option to enable the use of NAT-T (i.e. the encapsulation of ESP in UDP packets) if needed, which can help with clients that are behind restrictive firewalls.

    Ich teste das mal und berichte über Erfolg oder auch Mißerfolg.
#6
Hallo,
ist IPsec in der folgenden Konfiguration möglich, wenn auf der Seite A zwischen der Public IP und der OpnSense ein Transfernetz liegt?
Wie müsste die Seite B dann eingerichtet werden um die OpnSense auf der Seite A zu erreichen?
            -------                      -------           
            |  A  |                      |  B  |           
            -------                      -------           
                                                           
-----------------------------  ---------------------------
| WAN x.x.x.1               |  |                         |
| Router                    |  |     PPPoP x.x.x.2       |
| LAN 10.1.1.1              |  |                         |
-------------v-------v-------  -----------v---------------
              |       |                    |               
              |       v                    |               
              |       TK                   |               
              |     Anlage                 |               
              |                            |               
-------------v---------------  -----------v---------------
| WAN 10.1.1.2              |  | WAN PPPoE x.x.x.2       |
| Opensense                 |  | Opensense               |
| LAN 192.168.1.1           |  | LAN 192.168.2.1         |
|                           |  |                         |
-----------------------------  ---------------------------
| IPsec Phase 1             |  | IPsec Phase 1           |
| Interface WAN             |  | Interface WAN           |
| Remote Gateway x.x.x.2    |  | Remote Gateway ?.?.?.?  |
|                           |  |                         |
-----------------------------  ---------------------------
#7
Hello,
is it possible to run two IPsec tunnels over one public IP?

  • Site A (111.1.1.1) -> Site B (222.2.2.2)
  • Site A (111.1.1.1) -> Site C (222.3.3.3)
If possible, is there an example of how this is configured?
Thanks in advance
#8
Yes it works again, Thanks  :)
#9
Same issue with latest OPNsense 23.7.8-amd64
#10
German - Deutsch / Re: HTTP über WAN2
October 21, 2023, 03:19:21 PM
Funktioniert, man muss nicht einmal http zu WAN1 blockieren :)

Unter speedtest.net wird nun im Browser die WAN2-IP angezeigt, aber der Speed down/up Mbit/s ist der von WAN1
Ist = 208/16, Soll = 200/15

Unter breitbandmessung.de wird der Speed von WAN2 angezeigt, liegt aber nur knapp über 50% der möglichen Bandbreite
Ist = 346/174 Soll = 600/300 Mbit/s

Unter Reporting - Trafic mit Auswahl: WAN1 und WAN2 ist eindeutig zu sehen, das der speedtest.net im Browser über WAN1 läuft und breitbandmessung.de über WAN2.

Scheint so, als würde Okla die Regeln umgehen und für die Messung im Browser  andere Ports nutzen.
#11
German - Deutsch / Re: HTTP über WAN2
October 21, 2023, 12:33:48 PM
Danke für die Info.

Ich hatte im floating diese Regeln angelegt, scheinbar greifen diese dort nicht
IPv4 TCP   LAN_192_168_2_249 net   *   *   80 (HTTP)     WAN2 *   1   Browser über WAN2
IPv4 TCP   LAN_192_168_2_249 net   *   *    443 (HTTPS) WAN2 *   1   Browser über WAN2

Ich schau mal, ob die Regeln auf dem LAN Interface funktionieren.
#12
German - Deutsch / HTTP über WAN2
October 20, 2023, 07:13:59 PM
Hallo,

wir haben ein WAN1(ISP1) und ein neues WAN2(ISP2) Interface.

Über WAN1 sollen die eingerichteten IPSEC Verbindungen etc weiter laufen.

Über WAN2 soll jetzt der gesamte HTTP Trafic aus dem LAN laufen.

Wie konfiguriert man das Routing von HTTP von LAN auf WAN2?
#13
German - Deutsch / Re: Routing back WAN to WAN
July 02, 2023, 01:37:29 PM
Das Problem ist inzwischen gelöst, es ging insgesamt um 3 Mail-Systeme A, B und C
Die Lösungsansätze waren:

  • NAT-Reflection,
    Das hat aber bei den Mailservern nicht funktioniert, weil die Restriktionen, SPF und Reverse IP Auflösung etc, da nicht mitgespielt haben
  • Split DNS
    In der OPNsense = Services: Unbound DNS: Overrides,
    Die Mailserver A, B und C dort mit den IP der DMZ eingetragen.
    So konfiguriert, kommunizieren die Mailserver dann innerhalb der DMZ miteinander.
    Funktioniert mit dem Mailserver A und B aber der Applikationshost vom System C mochte die internen DNS-Zuordnungen gar nicht.

  • Auf System C ging es dann "back to the roots", die Mailserver A und B in die hosts eingetragen.
    Ping funktioniert, Mail nicht

  • Warum, weil Postfix, der Mailserver auf System-C, eine eigene hosts nutzt, also auch dort auch A und B eintragen.
    Funktioniert aber immer noch nicht.

  • Warum, der Postfix auf System-C ignoriert in der Standard Einstellung die hosts und geht nur über DNS
    Es muss noch die main.cf angepasst werden, dann schaut Postfix zuerst in die hosts und geht erst, wenn dort nichts passendes gefunden wird, über DNS
    /etc/postfix/main.cf

    smtp_host_lookup = native
Hat mich zwar einiges an Zeit und Recherche gekostet aber vielleicht helfen diese Infos ja auch dem ein oder anderen, schneller zum Ziel zu kommen.
#14
German - Deutsch / Routing back WAN to WAN
June 21, 2023, 02:41:27 AM
Hallo,

ich habe zwei mailserver für die domains a.de und b.de

mail.a.de = DMZ 10.10.10.10 <- NAT -> x.x.x.10 WAN
mail.b.de = DMZ 10.10.10.20 <- NAT -> x.x.x.20 WAN

mail.a.de kann extern senden und empfangen z.B. mit gmx.de
mail.b.de auch

Es gehen aber keine Mails von mail.a.de nach mail.b.de und umgekehrt.

Wie und wo müsste man das denn routen?


#15
Wie kann man einen Tunnel über "monit" komplett verbinden?

Aktuell ist es in monit service settings wie folgt konfiguriert und es wird nur Phase-1 verbunden.

Start : [ /usr/local/sbin/swanctl -i -i con2 ]
Stop  : [ /usr/local/sbin/swanctl -t -i con2 ]


Über console getestet, bekomme ich das gleiche Verhalten.


root@RZFW1:~ # /usr/local/sbin/swanctl -t -i con2

[IKE] deleting IKE_SA con2[275] between 78.94.223.133[78.94.223.133]...212.202.137.9[212.202.137.9]
[IKE] sending DELETE for IKE_SA con2[275]
[ENC] generating INFORMATIONAL_V1 request 3928440156 [ HASH D ]
[NET] sending packet: from 78.94.223.133[500] to 212.202.137.9[500] (108 bytes)
terminate completed successfully

root@RZFW1:~ # /usr/local/sbin/swanctl -i -i con2

[IKE] initiating Main Mode IKE_SA con2[276] to 212.202.137.9
[ENC] generating ID_PROT request 0 [ SA V V V V V ]
[NET] sending packet: from 78.94.223.133[500] to 212.202.137.9[500] (180 bytes)
[NET] received packet: from 212.202.137.9[500] to 78.94.223.133[500] (160 bytes)
[ENC] parsed ID_PROT response 0 [ SA V V V V ]
[IKE] received XAuth vendor ID
[IKE] received DPD vendor ID
[IKE] received FRAGMENTATION vendor ID
[IKE] received NAT-T (RFC 3947) vendor ID
[CFG] selected proposal: IKE:AES_CBC_128/HMAC_SHA2_256_128/PRF_HMAC_SHA2_256/MODP_2048
[ENC] generating ID_PROT request 0 [ KE No NAT-D NAT-D ]
[NET] sending packet: from 78.94.223.133[500] to 212.202.137.9[500] (396 bytes)
[NET] received packet: from 212.202.137.9[500] to 78.94.223.133[500] (396 bytes)
[ENC] parsed ID_PROT response 0 [ KE No NAT-D NAT-D ]
[ENC] generating ID_PROT request 0 [ ID HASH N(INITIAL_CONTACT) ]
[NET] sending packet: from 78.94.223.133[500] to 212.202.137.9[500] (108 bytes)
[NET] received packet: from 212.202.137.9[500] to 78.94.123.233[500] (92 bytes)
[ENC] parsed ID_PROT response 0 [ ID HASH ]
[IKE] IKE_SA con2[276] established between 78.94.223.133[78.94.223.133]...212.202.137.9[212.202.137.9]
[IKE] scheduling reauthentication in 3252s
[IKE] maximum IKE_SA lifetime 3609s
initiate completed successfully