Messages

Ich dachte es mir schon, dass dies der Grund ist - habe aber die github-Seite nicht gesehen.
Vielen Dank.

Ein bisschen beschäftigt mich noch die Fehlermeldung remote address unknown im Log.

Meine Vermutung war ja, dass die ipsec.conf Umschrift in swanctl.conf den fqdn der Fritzbox verliert. Sind beides Dynamische DNS Einträge...

Grüße,
Bernd

1) Muss dann nicht einfach nur bei Children die 2 Phase 2 Einträge rein? Sieht mir nach 2 separaten Connections aus? Im Prinzip also "tunnel isolation" in Phase 1 entsprechend alter GUI. Ich nehme an das ist auf 22.7.x nicht gesetzt bei dir?

Ich probiere das mal vor dem nächsten Update - weiß aber noch nicht genau, wann ich dazu komme.

Vielen Dank und Grüße
Bernd

Ich hab's hier gepostet: https://forum.opnsense.org/index.php?topic=32683.msg158174#msg158174

Die Vermutung betrifft ja nur die "neuen Verbindungen", nicht die Umschrift von ipsec.conf zu swanctl.conf ...

Danke und Grüße
Bernd

Gibts hier schon eine konkrete Idee? swanctl.conf falsch generiert?

Die Vermutung hatte ich, da 23.1 erst mit modp2048/DH Gruppe 14 startet und die Fritzbox initial modp1024/DH Gruppe 2 möchte. Siehe https://avm.de/service/vpn/fritzbox-mit-einem-firmen-ipsec-vpn-verbinden/

Grüße, Bernd

Hallo @groove21,

kannst Du posten was im Log geschieht, wenn die Verbindungen in 23.1 starten/nicht starten?

Meine ipsec Verbindungen zur Fritzbox funktionieren nach dem Update auf 23.1 leider auch nicht mehr. Hier habe ich meine Config und etwas aus dem Log gepostet: https://forum.opnsense.org/index.php?topic=32683.0

Außerdem meine Vermutung, dass die neue Verbindung mit strongswan mit den Fritzboxen nicht funktioniert, da opnsense die Verbindung nicht mehr mit der niedrigen DH Gruppe 2 initiieren möchte.

VG, Bernd

Ein bisschen mehr Info - ggf. ist es auch eher was für github siehe Limits https://forum.opnsense.org/index.php?topic=31860

Zu 1)
Den alten Verbindungen ipsec: der Log zeigt nur eine Verbindung mit zwei Phase 2 Einträgen.
Auf 22.7 sieht /usr/local/etc/ipsec.conf so aus:

Code Select Expand

# This file is automatically generated. Do not edit
config setup
  uniqueids = yes

conn con1-000
  aggressive = yes
  fragmentation = yes
  keyexchange = ikev1
  mobike = no
  reauth = yes
  rekey = yes
  forceencaps = no
  installpolicy = yes
  type = tunnel
 
 
  dpdaction = restart
  dpddelay = 10s
  dpdtimeout = 60s
 
 
  left = <wan-ip>
  right = <fqdn-fritz1>
  rightallowany = yes
  leftid = fqdn:<fqdn-sense>
  ikelifetime = 28800s
  lifetime = 3600s
  ike = aes256-sha512-modp1024!
  leftauth = psk
  rightauth = psk
  rightid = fqdn:<fqdn-fritz1>
  reqid = 1
  rightsubnet = 192.168.x.0/24
  leftsubnet = 192.168.y.0/24
  esp = aes256-sha512-modp1024!
  auto = route

conn con1-001
  aggressive = yes
  fragmentation = yes
  keyexchange = ikev1
  mobike = no
  reauth = yes
  rekey = yes
  forceencaps = no
  installpolicy = yes
  type = tunnel
 
 
  dpdaction = restart
  dpddelay = 10s
  dpdtimeout = 60s
 
 
  left = <wan-ip>
  right = <fqdn-fritz1>
  rightallowany = yes
  leftid = fqdn:<fqdn-sense>
  ikelifetime = 28800s
  lifetime = 3600s
  ike = aes256-sha512-modp1024!
  leftauth = psk
  rightauth = psk
  rightid = fqdn:<fqdn-fritz1>
  reqid = 2
  rightsubnet = 192.168.x.0/24
  leftsubnet = 192.168.z.0/24
  esp = aes256-sha512-modp1024!
  auto = route

conn con2
  aggressive = yes
  fragmentation = yes
  keyexchange = ikev1
  mobike = no
  reauth = yes
  rekey = yes
  forceencaps = no
  installpolicy = yes
  type = tunnel
 
 
  dpdaction = restart
  dpddelay = 10s
  dpdtimeout = 60s
 
 
  left = <wan-ip>
  right = <fqdn-fritz2>
  rightallowany = yes
  leftid = fqdn:<fqdn-sense>
  ikelifetime = 28800s
  lifetime = 3600s
  ike = aes256-sha512-modp1024!
  leftauth = psk
  rightauth = psk
  rightid = fqdn:<fqdn-fritz2>
  reqid = 3
  rightsubnet = 192.168.u.0/24
  leftsubnet = 192.168.y.0/24
  esp = aes256-sha512-modp1024!
  auto = route

include ipsec.opnsense.d/*.conf

Auf 23.1 sieht /usr/local/etc/swanctl/swanctl.conf so aus:

Code Select Expand

# This file is automatically generated. Do not edit
connections {
    con1 {
        unique = replace
        aggressive = yes
        version = 1
        mobike = no
        local_addrs = <wan-ip>
        local-0 {
            id = fqdn:<fqdn-sense>
            auth = psk
        }
        remote-0 {
            id = fqdn:<fqdn-fritz1>
            auth = psk
        }
        remote_addrs = %any
        encap = no
        dpd_delay = 10 s
        dpd_timeout = 60 s
        proposals = aes256-sha512-modp1024
        children {
            con1-000 {
                start_action = trap
                policies = yes
                mode = tunnel
                sha256_96 = no
                dpd_action = start
                local_ts = 192.168.y.0/24
                remote_ts = 192.168.x.0/24
                reqid = 1
                esp_proposals = aes256-sha512-modp1024
                life_time = 3600 s
            }
            con1-001 {
                start_action = trap
                policies = yes
                mode = tunnel
                sha256_96 = no
                dpd_action = start
                local_ts = 192.168.z.0/24
                remote_ts = 192.168.x.0/24
                reqid = 2
                esp_proposals = aes256-sha512-modp1024
                life_time = 3600 s
            }
        }
    }
    con2 {
        unique = replace
        aggressive = yes
        version = 1
        mobike = no
        local_addrs = <wan-ip>
        local-0 {
            id = fqdn:<fqdn-sense>
            auth = psk
        }
        remote-0 {
            id = fqdn:<fqdn-fritz2>
            auth = psk
        }
        remote_addrs = %any
        encap = no
        dpd_delay = 10 s
        dpd_timeout = 60 s
        proposals = aes256-sha512-modp1024
        children {
            con2-000 {
                start_action = trap
                policies = yes
                mode = tunnel
                sha256_96 = no
                dpd_action = start
                local_ts = 192.168.z.0/24
                remote_ts = 192.168.u.0/24
                reqid = 3
                esp_proposals = aes256-sha512-modp1024
                life_time = 3600 s
            }
        }
    }
}
pools {
}
secrets {
    ike-p1-0 {
        id-0 = fqdn:<fqdn-fritz1>
        secret = xx==
    }
    ike-p1-1 {
        id-0 = fqdn:<fqdn-fritz2>
        secret = yy==
    }
    ike-xy-ab-cd-ef-gh {
        id-0 = <fqdn-sense>
        secret = zz==
    }
}
# Include config snippets
include conf.d/*.conf

Zu 2)
Wenn ich es recht sehe, dann gibt es bei 23.1 aes256-sha512-modp1024 nicht mehr als Proposal.
Fritz schreibt dazu: https://avm.de/service/vpn/fritzbox-mit-einem-firmen-ipsec-vpn-verbinden/

"Die FRITZ!Box nutzt beim Schlüsselaustausch über Diffie-Hellman initial 1024 Bit (DH-Gruppe 2). Sie akzeptiert danach aber auch 768, 1536, 2048 und 3072 Bit (DH-Gruppe 1, 5, 14 und 15)."

Könnte also sein, dass 23.1/strongswan mit der Fritzbox nicht mehr geht?!

Spezial Danks an: https://forum.opnsense.org/index.php?topic=25540.0
22.7.11_1 läuft wieder.

Soweit für den Sonntag. Grüße
Bernd

Chears zusammen,

mein Problem ist wahrscheinlich ähnlich wie https://forum.opnsense.org/index.php?topic=32429.

Mit bis 22.7 funktionierten die ipsec-Verbindung zu zwei Fritzboxen, ab dem Update 23.1 (aktuell 23.1.1_2) nun nicht mehr.

Mein log sagt an, dass die alten ipsec Verbindungen die Gegenseiten nicht mehr finden:

Code Select Expand

2023-02-25T12:48:31 Informational charon 15[CFG] installing trap failed, remote address unknown
2023-02-25T12:48:31 Informational charon 15[CFG] installing 'con1-001'
2023-02-25T12:48:31 Informational charon 15[CFG] installing trap failed, remote address unknown
2023-02-25T12:48:31 Informational charon 15[CFG] installing 'con1-000'

Im Dashboard-Widget/Tunnel-Tab sehe ich in der Spalte Verbundungen:
<WAN-IP>
(%any)

In den Tunneleinstellungen stehen weiter die DynDns Hostnamen der Remote-Stellen. Aber die gleiche Fehlermeldung kommt auch, wenn ich die aktuelle IP der Gegenstelle eingebe. "remote address unknown" ...

Kann jemand helfen?

Ich kann mir zwei Arten vorstellen
1) Idee für einen Fix der alten Tunnelverbindungen

2) Migration zu strongswan... (hier ggf. gleich noch ein weiterer Post - nur soviel -> die Gegenstelle wird gefunden, aber der PSK-Austausch resultiert nach 5 Versuchen

Code Select Expand

establishing IKE_SA failed, peer not responding )

Danke im Voraus,
Bernd

(Wireguard ist besser! I know, I use it and it just works... Bei einer FB ist's ggf wirklich eine Möglichkeit, bei der anderen nicht)

Ok, Quizmaster werden war eh mal mein Traum [emoji3].
Wenn ich recht verstehe, dann ist keins der beiden in 23.1 schon verschwunden oder steht einem Update im Weg.
Wahrscheinlich fahre ich dann zunächst weiter langsam zweigleisig und behalte Spurwechsel und Rente im Auge.


Gesendet von iPhone mit Tapatalk

Hallo zusammen,

da ich recht bald auf 23.1 updaten wollte einmal die Frage in die Runde: wisst ihr wie der Stand der beiden DDNS-Plugins ist?

- Die legacy-version zeigt ja unter 22.7 an, dass sie unter 22.7 nicht da sein wird, funktioniert gut und hat ein Widget.
- Die andere, neue Version scheint auch zu funktionieren, hat jedoch noch kein Widget.

Grüße, Bernd

As it is no longer a problem, I cannot reproduce it...

The "solution" was in some changes to the firewall rule:
- the alias for the internet host was saved as URL(IPs). Changing this to Host(s) - did the trick I think.
- But I also changed the Destination in the rule from WAN address to any.

Anyway the openVPN comes up and now I cannot revert this. In a strange way. Even a reimport of the config-file I used after the installer isn't reproducing the issue.

So long, thanks for reading,
Bernd

Hallo @zusammen,

Seit gestern, nach dem Umzug auf neue Hardware (IPU451), habe ich ein Problem mit meinen openvpn Verbindungen, bei dem ich nicht weiter weiß.

Ich habe zwei Server2server Verbindungen zu zwei gehosteten Servern mit festen IP4 Adressen.
Die Firewall-Regel wurde nicht verändert:
pass - IPv4 UDP - IP source server1 - * - WAN address - port_ovpn_1195     *   *   OpenVPN sever1
pass - IPv4 UDP - IP source server2 - * - WAN address - port_ovpn_1196     *   *   OpenVPN sever2

Beide Server laufen, (beide openvpn server auf der sense auch). Sie schicken auch Anfragen, die jedoch über eine floating rule geblockt werden.
Die Werte stimmen mit den s.o. überein, nur, dass eben Default deny / state violation rule greift obwohl ja "last match"...

D.h. die Regeln oben fühlen sich wohl nicht zuständig bei den Anfragen.

Meine Recherche hat mich bisher nicht wirklich weitergebracht. Da es eine Standard deny rule ist, scheint sie ja mit vielen Problemen/Konfigurationsfehlern einher zu gehen.

Viele Grüße und besten Dank
Bernd

Edit:
------------
Ok, ich hab's schon auf Englisch geschrieben:
Als das Problem verschwunden ist, kann ich es nicht reproduzieren.
Es verschwand im Verlauf die Firewall rule etwas Unspezifischer zu machen und den Alias von einer Kategorie in die andere.
Aber ich kann das Problem nicht mit vernünftigem Aufwand reproduzieren (d.h. eine komplette Neuinstallation habe ich nicht gemacht). Einlesen der ursprünglichen config-Datei, die den Fehler nach der Installation mitbrachte, "hilft" nicht. D.h. die alte Regel, der alte Alias funktioniert nun.
Falls sich das noch ändert, werde ich berichten...

Hi @all,

I'm running into a default deny issue on my openvpn servers I can not debug.

I have changed the hardware yesterday and imported the last config (changed the interface names by find and replace from igb to the detected igc). Everything is working as expected, ipsec, wireguard, haproxy etc. Only my openvpn servers on wan are no longer reachable for their endpoints.
The firewall rule on wan is running, expecting to pass traffic. But it won't hit the connection as before. Why?

I am really not sure if this hardware change has even something to do with it. But the timely connection is there.

Best, thank you for helping out,
Bernd

Hallo AndeK

ich habe nach den opnsense-docs https://docs.opnsense.org/manual/how-tos/wireguard-client.html noch eine NAT/ Port-Forwarding Regel drin.

Vielleicht fehlt die noch?

Gruß, Bernd

Hallo AndreK,

das sieht weniger nach der Anleitung, ein wenig mehr nach Freestyle aus  :)

Ich denke die "AllowedIPs" sollten zum Netz von "Address" gehören.

Was ist die Idee hinter dem "192.168.106.0/24"? Dass die DNS-Server erreicht werden?

(es sieht irgendwie auch nicht richtig aus, dass das schon mit Interface vorhandene Netz "192.168.106.0/24" auch über wg0 geroutet werden soll. Wahrscheinlich gibt es dafür schon eine Route über 192.168.106.X/24)

Grüße, Bernd

Thanks for the clarification and the link, that makes sense.

Best, Bernd