Messages

1

German - Deutsch / Re: IPsec MTU nach Neustart des Systems wieder auf 1400

« on: January 09, 2020, 12:08:37 pm »

Wir haben mehrere Tunnel (IPsec / OVPN) welche mittels OSPF ein FailOver bilden. Einige Anwendungen und Clients unterstützen nur eine MTU von 1500. Eine Änderung der MTU am LAN-Interface kommt somit auch nicht in Frage.

2

German - Deutsch / IPsec MTU nach Neustart des Systems wieder auf 1400

« on: January 07, 2020, 11:59:33 am »

Hallo zusammen,

wir haben die MTU für einen unserer IPsec-Tunnel auf 1500 geändert. (über die Weboberfläche).

Nach einem Neustart ist diese aber wieder auf std. 1400. Man muss dann nochmal man. save klicken, in der Interface-Config.

Firmware. 19.7.8

Hat jemand das selbe Problem?

LG

3

German - Deutsch / Re: Niedrige Bandbreite mit OpenVPN

« on: October 31, 2019, 10:14:37 am »

Sowohl Appliances als auch VMs:

Appliance 1/2:

2x 1GHz / 4x 1 GHz
4 GB RAM
16 GB SSD
GBit Ehternetports


VM:

4x 2.10 GHz mit AES-NI
4 GB RAM
70 GB
GBit Ehternetports

Die Themen betreffen sowohl unsere Koaxialleitung (600/60) als auch unsere DSL-Leitungen (100/30). BIsher hatten wir noch nie mehre Bandbreite. Die Tunnel wurden erst frisch konfiguriert.

4

German - Deutsch / Niedrige Bandbreite mit OpenVPN

« on: October 31, 2019, 09:44:01 am »

Hallo zusammen,

leider haben wir Probleme mit unseren OpenVPN-Tunneln.

Wir erreichen sowohl im Download als auch im Upload maximal 5Mbit/s mit UDP und maximal 22 Mbit/s mit TCP.
Änderungen im Bereich der Verschlüsselung verändern nur minimal das Ergebnis. Auch die MTU/MSS beinflussen die Bandbreite des Tunnels nicht. Die Leitung/en sind jedoch voll funktionstüchtig. Wir setzen die OPNsense-Version 19.7.5 ein.

Vielleicht hat jemand schon Erfahrungen damit gemacht...

Danke im Voraus!

5

German - Deutsch / Re: Squid Proxy hängt sich auf

« on: September 25, 2019, 10:16:18 am »

Hallo zusammen,

nach weiteren Tests konnten wir feststellen, das das IDS/IPS für das Problem verantwortlich ist und die DNS-Anfragen vom Proxy blockt. Das Problem ist also behoben!

6

German - Deutsch / [GELÖST] Squid Proxy hängt sich auf

« on: September 16, 2019, 10:38:39 am »

Hallo in die Runde,

wir haben folgendes Problem:

Unser Webproxy (Squid) hängt sich immer wieder auf bzw. beantwortet keine DNS-Anfragen mehr. Dies Äußert sich dadurch, dass es beim Aufrufen einer Website zu einem Timeout kommt.

Gegenmaßnahmen und Tests welche wir schon gemacht haben:


-Versch. DNS-Server eingestellt (lokal etc.)

-LogFile durchsucht keine besonderen Einträge gefunden... bis auf
"kid1| ERROR: negotiating TLS on FD 49: error:14090086:SSL routines:ssl3_get_server_certificate:certificate verify failed (1/-1/0)"
kann das damit zusammenhängen?

-Neustart des Proxys -> behebt Problem temporär

Auch ein erneutes sichern der Config behebt das Problem temporär und geht aber bedeutend schneller als ein gesamter Restart des Webproxys. Wir haben uns jetzt mit einem Cronjob geholfen der alle 5 min die Konfiguration neu lädt. Das ist aber keine schöne und stabile Lösung...

Danke im Voraus!

7

German - Deutsch / Re: IPSEC-Tunnel Verbindungsabbrüche

« on: September 02, 2019, 12:59:08 pm »

Jetzt bekomme ich folgende Meldungen... sobald ich den Tunnel nach einem Verbindungsabbruch wieder aufbauen will...


Aug 30 08:42:00   charon: 10[KNL] <con5|8> querying policy 0.0.0.0/0 === 0.0.0.0/0 in failed, not found
Aug 30 08:41:59   charon: 12[CFG] trap not found, unable to acquire reqid 0
Aug 30 08:41:59   charon: 12[KNL] creating acquire job for policy 78.94.254.119/32 === 213.202.237.174/32 with reqid {0}
Aug 30 08:41:59   charon: 12[KNL] received an SADB_ACQUIRE with policy id 2 but no matching policy found
Aug 30 08:41:58   charon: 12[CFG] trap not found, unable to acquire reqid 0

8

German - Deutsch / Re: IPSEC-Tunnel Verbindungsabbrüche

« on: August 26, 2019, 04:54:28 pm »

Aug 26 16:53:18    charon: 06[CFG] trap not found, unable to acquire reqid 0
Aug 26 16:53:18    charon: 11[KNL] creating acquire job for policy 213.202.237.174/32 === 78.94.254.119/32 with reqid {0}
Aug 26 16:53:18    charon: 11[KNL] received an SADB_ACQUIRE with policy id 2 but no matching policy found
Aug 26 16:53:14    charon: 11[NET] <con1|4> sending packet: from 213.202.237.174[4500] to 78.94.254.119[4500] (65 bytes)
Aug 26 16:53:14    charon: 11[ENC] <con1|4> generating INFORMATIONAL request 2 [ N(AUTH_FAILED) ]
Aug 26 16:53:14    charon: 11[IKE] <con1|4> tried 1 shared key for '213.202.237.174' - '78.94.254.119', but MAC mismatched
Aug 26 16:53:14    charon: 11[ENC] <con1|4> parsed IKE_AUTH response 1 [ IDr AUTH N(ESP_TFC_PAD_N) SA TSi TSr N(AUTH_LFT) N(MOBIKE_SUP) N(ADD_4_ADDR) N(ADD_4_ADDR) N(ADD_4_ADDR) N(ADD_4_ADDR) N(ADD_4_ADDR) N(ADD_4_ADDR) N(ADD_4_ADDR) N(ADD_4_ADDR) ]
Aug 26 16:53:14    charon: 11[NET] <con1|4> received packet: from 78.94.254.119[4500] to 213.202.237.174[4500] (349 bytes)
Aug 26 16:53:14    charon: 11[NET] <con1|4> sending packet: from 213.202.237.174[4500] to 78.94.254.119[4500] (446 bytes)
Aug 26 16:53:14    charon: 11[ENC] <con1|4> generating IKE_AUTH request 1 [ IDi N(INIT_CONTACT) CERTREQ IDr AUTH N(ESP_TFC_PAD_N) SA TSi TSr N(MOBIKE_SUP) N(ADD_4_ADDR) N(ADD_4_ADDR) N(ADD_4_ADDR) N(ADD_4_ADDR) N(ADD_4_ADDR) N(ADD_4_ADDR) N(ADD_4_ADDR) N(ADD_4_ADDR) N(MULT_AUTH) N(EAP_ONLY) N(MSG_ID_SYN_SUP) ]
Aug 26 16:53:14    charon: 11[IKE] <con1|4> establishing CHILD_SA con1{2}
Aug 26 16:53:14    charon: 11[IKE] <con1|4> authentication of '213.202.237.174' (myself) with pre-shared key
Aug 26 16:53:14    charon: 11[IKE] <con1|4> sending cert request for "C=DE, ST=Nordrhein-Westfahlen, L=D??ren, O=DI-Gruppe, E=orgdv@di-gruppe.de, CN=opnsense-proxy-ssl-ca"
Aug 26 16:53:14    charon: 11[IKE] <con1|4> sending cert request for "C=DE, ST=Nordrhein-Westfahlen, L=D??ren, O=DI Management, E=orgdv@di-gruppe.de, CN=OPENVPN_CA_IT_ROADWARRIOR"
Aug 26 16:53:14    charon: 11[IKE] <con1|4> sending cert request for "C=DE, ST=NRW, L=Dueren, O=JFG, E=orgdv@jagdfeld-gruppe.de, CN=jfg-rz001-fw001.jfg.one"
Aug 26 16:53:14    charon: 11[IKE] <con1|4> received cert request for "C=DE, ST=NRW, L=Dueren, O=JFG, E=orgdv@jagdfeld-gruppe.de, CN=jfg-rz001-fw001.jfg.one"
Aug 26 16:53:14    charon: 11[CFG] <con1|4> selected proposal: IKE:AES_GCM_16_256/PRF_HMAC_SHA2_512/MODP_2048
Aug 26 16:53:14    charon: 11[ENC] <con1|4> parsed IKE_SA_INIT response 0 [ SA KE No N(NATD_S_IP) N(NATD_D_IP) CERTREQ N(FRAG_SUP) N(HASH_ALG) N(CHDLESS_SUP) N(MULT_AUTH) ]
Aug 26 16:53:14    charon: 11[NET] <con1|4> received packet: from 78.94.254.119[500] to 213.202.237.174[500] (489 bytes)
Aug 26 16:53:14    charon: 11[NET] <con1|4> sending packet: from 213.202.237.174[500] to 78.94.254.119[500] (456 bytes)
Aug 26 16:53:14    charon: 11[ENC] <con1|4> generating IKE_SA_INIT request 0 [ SA KE No N(NATD_S_IP) N(NATD_D_IP) N(FRAG_SUP) N(HASH_ALG) N(REDIR_SUP) ]
Aug 26 16:53:14    charon: 11[IKE] <con1|4> initiating IKE_SA con1[4] to 78.94.254.119
Aug 26 16:53:14    charon: 13[CFG] received stroke: initiate 'con1'
Aug 26 16:53:07    charon: 13[CFG] trap not found, unable to acquire reqid 0
Aug 26 16:53:07    charon: 14[KNL] creating acquire job for policy 213.202.237.174/32 === 176.94.251.183/32 with reqid {0}
Aug 26 16:53:07    charon: 14[KNL] received an SADB_ACQUIRE with policy id 6 but no matching policy found
Aug 26 16:53:05    charon: 14[CFG] trap not found, unable to acquire reqid 0
Aug 26 16:53:05    charon: 13[KNL] creating acquire job for policy 213.202.237.174/32 === 78.94.254.119/32 with reqid {0}
Aug 26 16:53:05    charon: 13[KNL] received an SADB_ACQUIRE with policy id 2 but no matching policy found

9

German - Deutsch / Re: IPSEC-Tunnel Verbindungsabbrüche

« on: August 26, 2019, 04:25:13 pm »

Wenn es nochmal auftritt stelle ich es rein! Danke schonmal...

10

German - Deutsch / IPSEC-Tunnel Verbindungsabbrüche

« on: August 26, 2019, 01:27:53 pm »

Hallo OPNsense-Community,

leider habe ich folgendes Problem:

Ich würde gerne zwei bzw. mehrere route-based IPSec-Tunnel in unser Rechenzentrum aufbauen. Leider bricht aber die Verbindung sporadisch ab sobald ich mehr als einen Tunnel (Phase1) laufen lasse.

Die Konfiguration der Phasen ist bis auf den PSK und VTI-IPs identisch. Wenn ihr weitere Informationen braucht füge ich diese gerne hinzu. Ich bin neu im Bereich IPsec unter opnsense, von daher bin ich für eure Hilfe sehrdankbar!

LG