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

Pages: [1] 2

German - Deutsch / Re: Kein Durchsatz durch VPN-Tunnel nach unterschiedlicher Zeit

« on: May 02, 2020, 02:52:15 am »

Klar, kein Problem.

Die OPNSense von meinem Netz zuhause läuft direkt auf der Hardware:

CPU: i5-7500, RAM: 16 GB DDR4-2400, SATA-SSD 120GB, Mainboard MSI B110M ECO, Netzwerkkarten: Intel X520-DA2 (2x 10 GBit/s), 1x Quad-Port Intel PCIe.
Angebunden an ein TC-4400 Kabelmodem im Bridge-Mode, d.h. OPNSense hat die WAN-IP direkt und keine Schweinereien mit NAT-T etc.
Das Netzwerk verteilt sich über drei Stockwerke, im Keller der Serverraum mit Modem, Firewall, NAS und einem kleinen 4x 10 GBit/s Mikrotik-Switch, EG und OG haben je einen großen Mikrotik Switch mit 24 Ports + 2x 10 Gbit/s. Die laufen auch alle als Switch und nicht als Router. Die Workstation (mit der ich die VPN-Verbindung aufbaue) ist also bis zur OPNSense mit 10 GBit/s angebunden. Im internen Netzwerk gibt es zumindest keine Fehler (Paketverluste, Fragmentierung, ...).

Auf der anderen Seite an einem Telekom-DSL Anschluss mit reinem DSL-Modem steht wieder eine OPNSense (Supermicro Board mit Atom C2558, 8 GB RAM, SSD, 4x 1 GBit/s Intel onboard, OPNSense läuft direkt auf der Hardware), die direkt die externe IP hat. Netzwerk ist ebenfalls ein Mikrotik-Setup mit 5x 24 Port Switchen (ca. 100 Geräte) und 12 VLANs. Die Geräte auf die ich per VPN und SSH/RDP/VNC zugreife sind allerdings per Kabel im Kernnetz, also kein VLAN. Auch hier, das interne Netz ist völlig unauffällig.

Anbei noch der vereinfachte Netzwerkplan von meinem Zuhause, das Büro ist eigentlich redundant, da habe ich grad keinen Plan zur Hand. Nach der OPNSense kommt der Hauptswitch, an dem direkt die Server hängen. Weitere Switches hängen direkt am Hauptswitch, die VLANs per extra Trunk direkt an der OPNSense.

German - Deutsch / Kein Durchsatz durch VPN-Tunnel nach unterschiedlicher Zeit

« on: May 01, 2020, 02:28:38 pm »

Hallo,

ich habe seit längerem ab und zu Probleme mit meinen VPNs. In der Regel arbeitet alles einwandfrei, aber es geschieht öfter das nach unterschiedlicher Länge der Verbindungsdauer der Tunnel einfach "stirbt". Ich benutze grundsätzlich dieses Setup: EAP-MSCHAPv2 via IKEv2

Gegenstelle ist meine Workstation zuhause, aktuellstes Windows 10 mit dem eingebauten VPN-Client. Über die VPN-Verbindung in mein Büro benutze ich hauptsächlich klassischen Kram wie SSH, VNC, RDP. Das Problem äußert sich dann wie folgt, dass die Verbindung mit den remote-Servern verloren geht, und auch nicht wiederhergestellt werden kann. Währenddessen zeigen sowohl Windows als auch OPNSense noch einen bestehenden Tunnel an. Das Problem kann nach Stunden oder auch Minuten auftreten, das ist vollkommen zufällig. Wenn ich parallel eine SSH-Verbindung ohne VPN per Port Forwarding aufbaue, bleibt diese bestehen, d.h. es liegt wahrscheinlich nicht an Problemen mit dem Internet.

Die Logfiles zeigen, dass es die OPNSense trotz totem Tunnel noch "mitbekommt", wenn ich bei Windows die VPN-Verbindung trenne. Nach einem Neuaufbau der Verbindung funktioniert alles wieder, bis zum nächsten Mal jedenfalls.

Wie kann ich die Ursache des Problems herausfinden ?

Logs der OPNSense, die Verbindung ging irgendwann zwischen 13:42 und 13:52 (SSH Session vom Server aufgrund von Timeout geschlossen) verloren. RASMan auf Windows meldet nichts, außer dem manuellen Trennen der Verbindung:

Code: [Select]

2020-05-01T14:10:03	charon: 11[CFG] <con1|57> lease 10.0.250.1 by 'vpnuser@domain.tld' went offline
2020-05-01T14:10:03	charon: 11[NET] <con1|57> sending packet: from VPN-SERVERIP[4500] to CLIENT-WAN-IP[4500] (80 bytes)
2020-05-01T14:10:03	charon: 11[ENC] <con1|57> generating INFORMATIONAL response 9 [ ]
2020-05-01T14:10:03	charon: 11[IKE] <con1|57> IKE_SA deleted
2020-05-01T14:10:03	charon: 11[IKE] <con1|57> deleting IKE_SA con1[57] between VPN-SERVERIP[vpn.domain.tld]...CLIENT-WAN-IP[192.168.X.YYY]
2020-05-01T14:10:03	charon: 11[IKE] <con1|57> received DELETE for IKE_SA con1[57]
2020-05-01T14:10:03	charon: 11[ENC] <con1|57> parsed INFORMATIONAL request 9 [ D ]
2020-05-01T14:10:03	charon: 11[NET] <con1|57> received packet: from CLIENT-WAN-IP[4500] to VPN-SERVERIP[4500] (80 bytes)
2020-05-01T14:10:03	charon: 11[NET] <con1|57> sending packet: from VPN-SERVERIP[4500] to CLIENT-WAN-IP[4500] (80 bytes)
2020-05-01T14:10:03	charon: 11[ENC] <con1|57> generating INFORMATIONAL response 8 [ D ]
2020-05-01T14:10:03	charon: 11[IKE] <con1|57> CHILD_SA closed
2020-05-01T14:10:03	charon: 11[IKE] <con1|57> sending DELETE for ESP CHILD_SA with SPI cf3334c8
2020-05-01T14:10:03	charon: 11[IKE] <con1|57> closing CHILD_SA con1{295} with SPIs cf3334c8_i (87798 bytes) 6cd39980_o (60176 bytes) and TS 0.0.0.0/0 === 10.0.250.1/32
2020-05-01T14:10:03	charon: 11[IKE] <con1|57> received DELETE for ESP CHILD_SA with SPI 6cd39980
2020-05-01T14:10:03	charon: 11[ENC] <con1|57> parsed INFORMATIONAL request 8 [ D ]
2020-05-01T14:10:03	charon: 11[NET] <con1|57> received packet: from CLIENT-WAN-IP[4500] to VPN-SERVERIP[4500] (80 bytes)
2020-05-01T13:42:21	charon: 09[NET] <con1|57> sending packet: from VPN-SERVERIP[4500] to CLIENT-WAN-IP[4500] (80 bytes)
2020-05-01T13:42:21	charon: 09[ENC] <con1|57> generating INFORMATIONAL response 7 [ D ]
2020-05-01T13:42:21	charon: 09[IKE] <con1|57> CHILD_SA closed
2020-05-01T13:42:21	charon: 09[IKE] <con1|57> sending DELETE for ESP CHILD_SA with SPI c697ebff
2020-05-01T13:42:21	charon: 09[IKE] <con1|57> closing CHILD_SA con1{294} with SPIs c697ebff_i (0 bytes) a504004a_o (0 bytes) and TS 0.0.0.0/0 === 10.0.250.1/32
2020-05-01T13:42:21	charon: 09[IKE] <con1|57> received DELETE for ESP CHILD_SA with SPI a504004a
2020-05-01T13:42:21	charon: 09[ENC] <con1|57> parsed INFORMATIONAL request 7 [ D ]
2020-05-01T13:42:21	charon: 09[NET] <con1|57> received packet: from CLIENT-WAN-IP[4500] to VPN-SERVERIP[4500] (80 bytes)
2020-05-01T13:37:32	charon: 09[NET] <con1|57> sending packet: from VPN-SERVERIP[4500] to CLIENT-WAN-IP[4500] (208 bytes)
2020-05-01T13:37:32	charon: 09[ENC] <con1|57> generating CREATE_CHILD_SA response 6 [ N(ESP_TFC_PAD_N) SA No TSi TSr ]
2020-05-01T13:37:32	charon: 09[IKE] <con1|57> CHILD_SA con1{295} established with SPIs cf3334c8_i 6cd39980_o and TS 0.0.0.0/0 === 10.0.250.1/32
2020-05-01T13:37:32	charon: 09[CFG] <con1|57> selected proposal: ESP:AES_CBC_256/HMAC_SHA1_96/NO_EXT_SEQ
2020-05-01T13:37:32	charon: 09[ENC] <con1|57> parsed CREATE_CHILD_SA request 6 [ SA No TSi TSr ]
2020-05-01T13:37:32	charon: 09[NET] <con1|57> received packet: from CLIENT-WAN-IP[4500] to VPN-SERVERIP[4500] (336 bytes)
2020-05-01T13:37:21	charon: 08[IKE] <con1|57> CHILD_SA closed

19.7 Legacy Series / reset particular service configuration (ipsec vpn)

« on: December 09, 2019, 10:39:46 pm »

hello,

i am on the latest version of opnsense with some massive problems with vpn. i just can't connect with my mobole clients anymore (using IKEv2+MSCHapv2/EAP, error: charon: 15[IKE] <con1|8> no EAP key found for hosts '***hostname***' - '***ikeuser***'). The configuration ist just the same as on other opnsense machines i use - i think somehow the IPSEC part is broken, as the service does not start automatically at boot, and the ipsec firewall rules aren't inserted automatically anymore. maybe a recent hardware change messed something up.
So, is there a possibility to reset/reconfigure the ipsec part only to default state?

German - Deutsch / Seltsames Problem mit VLAN (timeout außer während shutdown/boot)

« on: October 06, 2019, 07:09:34 pm »

Hallo,

ich habe neuerdings ein seltsames Problem mit meiner OPNSense. Kurz zum Aufbau:

OPNSense:
onboard Intel NIC Port 1: direkt angebunden an LTE Modem für WAN-Failover
onboard Intel NIC Port 2: Switch für ein separates zweites LAN
Mellanox Connect-X2 Port 1: WAN-Uplink Glasfaser (1 Gbit/s)
Mellanox Connect-X2 Port 2: Trunk zu Mikrotik CRS305G-1G-4S+ (LAN untagged, GUEST tagged VID 10)

Auf dem Mikrotik läufts CapsMan um meine Access Points zu verwalten, diese bieten zwei Netze an, einmal für Gäste, einmal Intern. Der Verkehr der Gäste wird mit der VLAN-ID 10 getagged, alles aus dem internen LAN+WLAN ist untagged.
An der OPNSense ist das VLAN entsprechend eingerichtet, und es hat auch einige Monate einwandfrei funktioniert. Innerhalb des Netzwerkes funktioniert alles, ich kann einen Gast vom Mikrotik aus über das ganze Netzwerk hinweg anpingen, und zurück. Es hakt also irgendwo zwischen OPNSense und dem Mikrotik, diese können sich gegenseitig nicht anpingen - mittels tcpdump ist auch kein Traffic zu finden. Firewall-Log, OPNSense-Log komplett unauffällig.
Inzwischen habe ich stark die OPNSense in Verdacht - wenn ich auf dem Mikrotik konstant einen Ping auf die VLAN-IP der OPNSense laufen lasse, erhalte ich timeouts. Zufälligerweise habe ich dann einmal die OPNSense neugestartet, kurz nach dem Klick auf Shutdown gingen einige Pings während des Herunterfahrens durch und wurden beantwortet. Dasselbe passiert während des Hochfahrens, sobald dieses abgeschlossen ist, geht nichts mehr (timeout). Daraus werde ich leider nicht wirklich schlau, weil laut Live-View der Paketfilter nichts blockiert o.Ä.

Hat jemand eine Idee, was ich ausprobieren kann oder ob es noch eine Möglichkeit gibt genauer nachzuschauen was hier passiert ?

Sensei / Re: Sensei on OPNsense - Application based filtering

« on: September 22, 2019, 11:42:12 pm »

Quote from: mb on September 19, 2019, 06:59:08 pm

@marcri, thanks for the feedback. @nullinger, then it looks like if you have just the username, we have an issue. We were just about to do a code freeze for 1.0.3. Good timing Looks like an easy fix.

That's true, i am using a local mail relay which allows mail without authentication from specific IPs. Thank you very much !

Sensei / Re: Sensei on OPNsense - Application based filtering

« on: September 17, 2019, 10:41:50 pm »

Hello @mb,

i am on my third day with sensei, and i like it very much. Today, i tried to setup reports by mail and got some problems because the system sets "autoreports@sunnyvalley.io" as sender. As my mail relay does not allow sender addresses with non-local/external domains it would be very nice to have the possibility to set an own sender address.

Thanks !

German - Deutsch / Re: Probleme mit X520-DA2: no carrier - neueren Intel Treiber kompilieren ?

« on: February 05, 2019, 10:12:20 pm »

Ich vermute hier das Problem aber tatsächlich im Treiber, unter nicht BSD-Systemen gibt es ja keine Probleme. Nachdem ich noch eine Mellanox Connect-X2 mit zwei Ports auftreiben konnte, läuft jetzt für das erste diese produktiv, und mit der Intel experimentiere ich im Backup-System weiter. Ich würde halt gerne den neuesten Treiber ausprobieren, dafür muss ich aber den Kernel neu kompilieren, da der bisherige Treiber fest einkompiliert ist.

German - Deutsch / Re: Probleme mit X520-DA2: no carrier - neueren Intel Treiber kompilieren ?

« on: February 02, 2019, 01:28:18 am »

Update: Das Problem hängt direkt mit VLANs zusammen. Sobald nur ein Tag gesetzt wird (Schnittstellen -> Andere Typen -> VLAN) ist nach dem nächsten Reboot das Interface mit "no carrier" offline. Auch, wenn noch keine Zuweisung erfolgt ist. Bis dahin funktioniert die Schnittstelle sowie das VLAN korrekt. Wird der VLAN Tag wieder gelöscht, ist das Interface nach einem Reboot wieder funktional. Das Neuladen der Services bringt keine Abhilfe.

German - Deutsch / Probleme mit X520-DA2: no carrier - neueren Intel Treiber kompilieren ?

« on: January 31, 2019, 01:03:39 am »

Hallo,

ich habe meine alte OPNSense-Hardware ausgetauscht, und ein neues System aufgebaut - unter anderem mit einer originalen Intel X520-DA2. Mit der habe ich das Problem, das inzwischen einer der beiden Ports der X520 nicht mehr korrekt funktioniert. Es sieht so ähnlich aus, wie das Problem welches hier geschildert wird.

Zu Beginn, während des Setups und nach dem ersten Boot lief alles einwandfrei, ix0 = LAN, ix1 = WAN, alles online und sauber am funktionieren. Beim Update von 19.1-rc1 auf rc2 kam ix0 dann nicht mehr online. Das Webinterface sagt "Ethernet autoselect", ifconfig ix0 liefert "no carrier" aus. Der Switch am anderen Ende des Kabels zeigt "no link". ix1 funktioniert allerdings wie gehabt. Mittlerweile habe ich so gut wie alles ausprobiert:

Kabel getauscht, unter anderem andere DACs, oder auch Kupfer-SFPs
Switch getauscht
MSI-X deaktiviert
Manuelle Konfiguration der Linkgeschwindigkeit

Das führte zu keiner Änderung der Situation. Beim Booten einer Ubuntu-CD, oder auch einer festen Installation treten keine Probleme auf, beide Links funktionieren dauerhaft.
Weitere Tests haben ergeben, dass bei einem Reboot der Maschine der Link während des POST, Grub und dem Booten von OPNSense funktioniert und Pakete in beide Richtungen überträgt, und erst bei "configuring interfaces" verschwindet. Hier ein kurzes Youtube-Video, das den Switch zeigt. Der Ping geht auf ein normales GBit-Interface.

Daher vermute ich hier ein Problem mit dem in Free/Hardened-BSD ausgelieferten Treiber (3.2.12-k) und würde gerne den aktuellen Treiber direkt von Intel (3.3.6) kompilieren und testen. Mit FreeBSD und eventuellen Änderungen durch OPNSense bin ich im Gegensatz zu Linuxen nicht gut vertraut. Gibt es für die 19.1-rc2 schon Kernel-Sources ? Kann ich den neuen Treiber dann auch persistent installieren ?

19.1 Legacy Series / Re: Issues with IPSEC and Diffie Hellman Groups on 19.1

« on: December 29, 2018, 02:19:07 am »

I have a similar issue with the same possible cause. After importing configuration from 18.7 to 19.1 my IKEv2 VPNs are broken, the clients can't connect due to some errors with the DH Group

Code: [Select]

Dec 29 02:04:39 opnsense charon: 12[IKE] <40> XYZ is initiating an IKE_SA
Dec 29 02:04:39 opnsense charon: 12[IKE] <40> remote host is behind NAT
Dec 29 02:04:39 opnsense charon: 12[IKE] <40> DH group MODP_2048 inacceptable, requesting MODP_2048
Dec 29 02:04:39 opnsense charon: 12[ENC] <40> generating IKE_SA_INIT response 0 [ N(INVAL_KE) ]

DH Groups:

Code: [Select]

root@opnsense191:~ # ipsec listall | grep DH
    DH:CURVE_25519

root@opnsense187:~ # ipsec listall | grep DH
    DH:ECP_256
    DH:ECP_384
    DH:ECP_521
    DH:ECP_224
    DH:ECP_192
    DH:ECP_256_BP
    DH:ECP_384_BP
    DH:ECP_512_BP
    DH:ECP_224_BP
    DH:MODP_3072
    DH:MODP_4096
    DH:MODP_6144
    DH:MODP_8192
    DH:MODP_2048
    DH:MODP_2048_224
    DH:MODP_2048_256
    DH:MODP_1536
    DH:MODP_1024
    DH:MODP_1024_160
    DH:MODP_768
    DH:MODP_CUSTOM
    DH:CURVE_25519

18.7 Legacy Series / Re: LetsEncrypt Renewal failes due to DNS(?) error

« on: September 04, 2018, 10:53:29 am »

bump...

18.7 Legacy Series / LetsEncrypt Renewal failes due to DNS(?) error

« on: August 28, 2018, 04:40:18 pm »

Hello,

i just got a reminder email from letsencrypt that the certificate used for my opnsense will expire in a few days. so, i checked the opnsense why the automatic renewal failed.

Code: [Select]

[Tue Aug 28 16:34:21 CEST 2018] ACME_DIRECTORY='https://acme-v01.api.letsencrypt.org/directory'
[Tue Aug 28 16:34:21 CEST 2018] _ACME_SERVER_HOST='acme-v01.api.letsencrypt.org'
[Tue Aug 28 16:34:21 CEST 2018] DOMAIN_PATH='/var/etc/acme-client/home/yyy.xxxxxx.zz'
[Tue Aug 28 16:34:21 CEST 2018] '/var/etc/acme-client/challenges' does not contain 'dns'
[Tue Aug 28 16:34:21 CEST 2018] Using ACME_DIRECTORY: https://acme-v01.api.letsencrypt.org/directory
[Tue Aug 28 16:34:21 CEST 2018] _init api for server: https://acme-v01.api.letsencrypt.org/directory
[Tue Aug 28 16:34:21 CEST 2018] GET
[Tue Aug 28 16:34:21 CEST 2018] url='https://acme-v01.api.letsencrypt.org/directory'
[Tue Aug 28 16:34:21 CEST 2018] timeout=
[Tue Aug 28 16:34:21 CEST 2018] _CURL='curl -L --silent --dump-header /var/etc/acme-client/home/http.header  -g '
[Tue Aug 28 16:34:39 CEST 2018] Please refer to https://curl.haxx.se/libcurl/c/libcurl-errors.html for error code: 6
[Tue Aug 28 16:34:39 CEST 2018] ret='6'
[Tue Aug 28 16:34:39 CEST 2018] response
[Tue Aug 28 16:34:39 CEST 2018] Can not init api.
[Tue Aug 28 16:34:39 CEST 2018] Le_NextRenewTime='1534496697'
[Tue Aug 28 16:34:39 CEST 2018] _on_before_issue
[Tue Aug 28 16:34:39 CEST 2018] _chk_main_domain='yyy.xxxxxx.zz'
[Tue Aug 28 16:34:39 CEST 2018] _chk_alt_domains='thor.yyy.xxxxxx.zz'
[Tue Aug 28 16:34:39 CEST 2018] '/var/etc/acme-client/challenges' does not contain 'no'
[Tue Aug 28 16:34:39 CEST 2018] Le_LocalAddress
[Tue Aug 28 16:34:39 CEST 2018] d='yyy.xxxxxx.zz'
[Tue Aug 28 16:34:39 CEST 2018] Check for domain='yyy.xxxxxx.zz'
[Tue Aug 28 16:34:39 CEST 2018] _currentRoot='/var/etc/acme-client/challenges'
[Tue Aug 28 16:34:39 CEST 2018] d='thor.yyy.xxxxxx.zz'
[Tue Aug 28 16:34:39 CEST 2018] Check for domain='thor.yyy.xxxxxx.zz'
[Tue Aug 28 16:34:40 CEST 2018] _currentRoot='/var/etc/acme-client/challenges'
[Tue Aug 28 16:34:40 CEST 2018] d
[Tue Aug 28 16:34:40 CEST 2018] '/var/etc/acme-client/challenges' does not contain 'apache'
[Tue Aug 28 16:34:40 CEST 2018] config file is empty, can not read CA_KEY_HASH
[Tue Aug 28 16:34:40 CEST 2018] _saved_account_key_hash
[Tue Aug 28 16:34:40 CEST 2018] Using config home:/var/etc/acme-client/home
[Tue Aug 28 16:34:40 CEST 2018] ACME_DIRECTORY='https://acme-v01.api.letsencrypt.org/directory'
[Tue Aug 28 16:34:40 CEST 2018] _ACME_SERVER_HOST='acme-v01.api.letsencrypt.org'
[Tue Aug 28 16:34:40 CEST 2018] _init api for server: https://acme-v01.api.letsencrypt.org/directory
[Tue Aug 28 16:34:40 CEST 2018] GET
[Tue Aug 28 16:34:40 CEST 2018] url='https://acme-v01.api.letsencrypt.org/directory'
[Tue Aug 28 16:34:40 CEST 2018] timeout=
[Tue Aug 28 16:34:40 CEST 2018] _CURL='curl -L --silent --dump-header /var/etc/acme-client/home/http.header  -g '
[Tue Aug 28 16:34:40 CEST 2018] Please refer to https://curl.haxx.se/libcurl/c/libcurl-errors.html for error code: 6
[Tue Aug 28 16:34:40 CEST 2018] ret='6'
[Tue Aug 28 16:34:40 CEST 2018] response
[Tue Aug 28 16:34:40 CEST 2018] Can not init api.
[Tue Aug 28 16:34:40 CEST 2018] RSA key
[Tue Aug 28 16:34:40 CEST 2018] _URGLY_PRINTF='1'
[Tue Aug 28 16:34:40 CEST 2018] _URGLY_PRINTF='1'
[Tue Aug 28 16:34:41 CEST 2018] Registering account
[Tue Aug 28 16:34:41 CEST 2018] url
[Tue Aug 28 16:34:41 CEST 2018] payload='{"resource": "", "contact": ["mailto: my@email.tld"], "terms-of-service-agreed": true, "agreement": ""}'
[Tue Aug 28 16:34:41 CEST 2018] Use cached jwk for file: /var/etc/acme-client/accounts/59d40271aaf3c9.74162669/account.key
[Tue Aug 28 16:34:41 CEST 2018] Get nonce. ACME_DIRECTORY='https://acme-v01.api.letsencrypt.org/directory'
[Tue Aug 28 16:34:41 CEST 2018] GET
[Tue Aug 28 16:34:41 CEST 2018] url='https://acme-v01.api.letsencrypt.org/directory'
[Tue Aug 28 16:34:41 CEST 2018] timeout=
[Tue Aug 28 16:34:41 CEST 2018] _CURL='curl -L --silent --dump-header /var/etc/acme-client/home/http.header  -g '
[Tue Aug 28 16:34:41 CEST 2018] Please refer to https://curl.haxx.se/libcurl/c/libcurl-errors.html for error code: 6
[Tue Aug 28 16:34:41 CEST 2018] ret='6'
[Tue Aug 28 16:34:41 CEST 2018] Can not connect to https://acme-v01.api.letsencrypt.org/directory to get nonce.
[Tue Aug 28 16:34:41 CEST 2018] Register account Error:
[Tue Aug 28 16:34:41 CEST 2018] _on_issue_err
[Tue Aug 28 16:34:41 CEST 2018] Please check log file for more details: /var/log/acme.sh.log
[Tue Aug 28 16:34:41 CEST 2018] _chk_vlist

curl error 6 would be "CURLE_COULDNT_RESOLVE_HOST - Couldn't resolve host. The given remote host was not resolved." But, DNS is working from local console and network, curl works, too.

Code: [Select]

root@opnsense:~ # nslookup acme-v01.api.letsencrypt.org
Server:         127.0.0.1
Address:        127.0.0.1#53

Non-authoritative answer:
acme-v01.api.letsencrypt.org    canonical name = api.letsencrypt.org-ng.edgekey.net.
api.letsencrypt.org-ng.edgekey.net      canonical name = e14990.dscx.akamaiedge.net.
Name:   e14990.dscx.akamaiedge.net
Address: 95.101.64.58
Name:   e14990.dscx.akamaiedge.net
Address: 2a02:26f0:12:392::3a8e
Name:   e14990.dscx.akamaiedge.net
Address: 2a02:26f0:12:384::3a8e

root@opnsense:~ # curl https://acme-v01.api.letsencrypt.org/directory
{
  "key-change": "https://acme-v01.api.letsencrypt.org/acme/key-change",
  "meta": {
    "caaIdentities": [
      "letsencrypt.org"
    ],
    "terms-of-service": "https://letsencrypt.org/documents/LE-SA-v1.2-November-15-2017.pdf",
    "website": "https://letsencrypt.org"
  },
  "new-authz": "https://acme-v01.api.letsencrypt.org/acme/new-authz",
  "new-cert": "https://acme-v01.api.letsencrypt.org/acme/new-cert",
  "new-reg": "https://acme-v01.api.letsencrypt.org/acme/new-reg",
  "revoke-cert": "https://acme-v01.api.letsencrypt.org/acme/revoke-cert",
  "xcqQXvXm2Sk": "https://community.letsencrypt.org/t/adding-random-entries-to-the-directory/33417"

I tried everything i could think of, like rebooting the machine, updating acme.sh to the latest version, and so on...

Any ideas ?

German - Deutsch / Re: WAN bleibt nach kurzem Provider-Ausfall offline

« on: July 11, 2018, 10:49:19 am »

Die Problematik trat eben wieder auf, nach einem Austausch des Hauptstromzählers war das Kabelmodem kurz stromlos (die OPNSense hat eine USV). Das Internet ging erst nach release und renew des WAN Interfaces...

German - Deutsch / WAN bleibt nach kurzem Provider-Ausfall offline

« on: May 22, 2018, 02:57:30 pm »

Hi,

vorher hatte mein Kabelanbieter einen kurzen Schluckauf (13:52 Uhr), die WAN-Verbindung der OPNSense kam danach aber nicht mehr selbstständig online. Zuerst habe ich das Kabelmodem neugestartet (14:27 Uhr, obwohl Inet+Telefon Symbol leuchtete), dennoch passierte nichts und auch der Zugriff auf die Modem-GUI (192.168.100.1) lief in den Timeout.
Erst mit der OPNSense GUI konnte ich den Internetzugang wieder zum Leben erwecken, indem ich über Interfaces->Überblick die WAN-IP per release und renew erneuert habe. Die WAN-IP ist allerdings diesselbe wie vor dem Ausfall.
Das kam jetzt schon zweimal vor, gibt es eine Möglichkeit gegen solch einen Fehler etwas zu unternehmen ?
Anbei das Log:

Code: [Select]

May 22 14:40:02 	opnsense: /usr/local/etc/rc.dyndns: Dynamic DNS: (Success) IP Address Updated Successfully!
May 22 14:40:02 	opnsense: /usr/local/etc/rc.dyndns: Dynamic DNS: updating cache file /var/cache/dyndns_wan__1.cache: 111.222.111.94
May 22 14:40:00 	opnsense: /usr/local/etc/rc.dyndns: Dynamic DNS: (Success) IP Address Updated Successfully!
May 22 14:40:00 	opnsense: /usr/local/etc/rc.dyndns: Dynamic DNS: updating cache file /var/cache/dyndns_wan__0.cache: 111.222.111.94
May 22 14:38:19 	opnsense: /usr/local/etc/rc.newwanip: Dynamic DNS: (Success) IP Address Updated Successfully!
May 22 14:38:19 	opnsense: /usr/local/etc/rc.newwanip: Dynamic DNS: updating cache file /var/cache/dyndns_wan__1.cache: 111.222.111.94
May 22 14:38:17 	opnsense: /usr/local/etc/rc.newwanip: Dynamic DNS: (Success) IP Address Updated Successfully!
May 22 14:38:17 	opnsense: /usr/local/etc/rc.newwanip: Dynamic DNS: updating cache file /var/cache/dyndns_wan__0.cache: 111.222.111.94
May 22 14:38:14 	opnsense: /usr/local/etc/rc.newwanip: Adding static route for monitor 8.8.8.8 via 111.222.111.254
May 22 14:38:14 	opnsense: /usr/local/etc/rc.newwanip: Removing static route for monitor 8.8.8.8 via 111.222.111.254
May 22 14:38:13 	opnsense: /usr/local/etc/rc.dyndns: Dynamic DNS: (Success) IP Address Updated Successfully!
May 22 14:38:13 	opnsense: /usr/local/etc/rc.dyndns: Dynamic DNS: updating cache file /var/cache/dyndns_wan__1.cache: 111.222.111.94
May 22 14:38:11 	opnsense: /usr/local/etc/rc.dyndns: Dynamic DNS: (Success) IP Address Updated Successfully!
May 22 14:38:11 	opnsense: /usr/local/etc/rc.dyndns: Dynamic DNS: updating cache file /var/cache/dyndns_wan__0.cache: 111.222.111.94
May 22 14:38:07 	opnsense: /usr/local/etc/rc.newwanip: ROUTING: skipping IPv6 default route
May 22 14:38:07 	opnsense: /usr/local/etc/rc.newwanip: ROUTING: keeping current default gateway '111.222.111.254'
May 22 14:38:07 	opnsense: /usr/local/etc/rc.newwanip: ROUTING: setting IPv4 default route to 111.222.111.254
May 22 14:38:07 	opnsense: /usr/local/etc/rc.newwanip: ROUTING: IPv6 default gateway set to wan
May 22 14:38:07 	opnsense: /usr/local/etc/rc.newwanip: ROUTING: IPv4 default gateway set to wan
May 22 14:38:07 	opnsense: /usr/local/etc/rc.newwanip: ROUTING: entering configure using 'wan'
May 22 14:38:07 	opnsense: /usr/local/etc/rc.newwanip: On (IP address: 111.222.111.94) (interface: WAN[wan]) (real interface: re1).
May 22 14:38:07 	opnsense: /usr/local/etc/rc.newwanip: IP renewal is starting on 're1'
May 22 14:38:01 	opnsense: /status_interfaces.php: Clearing states to old gateway 111.222.111.254.
May 22 14:36:01 	opnsense: /usr/local/etc/rc.dyndns: Dynamic DNS () There was an error trying to determine the public IP for interface - wan(re1). Probably interface is not a WAN interface.
May 22 14:36:01 	opnsense: /usr/local/etc/rc.dyndns: Aborted IPv4 detection: no address for re1
May 22 14:36:00 	opnsense: /usr/local/etc/rc.dyndns: Dynamic DNS () There was an error trying to determine the public IP for interface - wan(re1). Probably interface is not a WAN interface.
May 22 14:36:00 	opnsense: /usr/local/etc/rc.dyndns: Aborted IPv4 detection: no address for re1
May 22 14:32:01 	opnsense: /usr/local/etc/rc.dyndns: Dynamic DNS () There was an error trying to determine the public IP for interface - wan(re1). Probably interface is not a WAN interface.
May 22 14:32:01 	opnsense: /usr/local/etc/rc.dyndns: Aborted IPv4 detection: no address for re1
May 22 14:32:00 	opnsense: /usr/local/etc/rc.dyndns: Dynamic DNS () There was an error trying to determine the public IP for interface - wan(re1). Probably interface is not a WAN interface.
May 22 14:32:00 	opnsense: /usr/local/etc/rc.dyndns: Aborted IPv4 detection: no address for re1
May 22 14:29:06 	opnsense: /usr/local/etc/rc.dyndns: Dynamic DNS () There was an error trying to determine the public IP for interface - wan(re1). Probably interface is not a WAN interface.
May 22 14:29:06 	opnsense: /usr/local/etc/rc.dyndns: Aborted IPv4 detection: no address for re1
May 22 14:29:04 	opnsense: /usr/local/etc/rc.dyndns: Dynamic DNS () There was an error trying to determine the public IP for interface - wan(re1). Probably interface is not a WAN interface.
May 22 14:29:04 	opnsense: /usr/local/etc/rc.dyndns: Aborted IPv4 detection: no address for re1
May 22 14:29:02 	opnsense: /usr/local/etc/rc.linkup: ROUTING: skipping IPv6 default route
May 22 14:29:02 	opnsense: /usr/local/etc/rc.linkup: The command '/sbin/route add -'inet' default '111.222.111.254'' returned exit code '1', the output was 'route: writing to routing socket: Network is unreachable add net default: gateway 111.222.111.254 fib 0: Network is unreachable'
May 22 14:29:02 	opnsense: /usr/local/etc/rc.linkup: ROUTING: creating /tmp/re1_defaultgw using '111.222.111.254'
May 22 14:29:02 	opnsense: /usr/local/etc/rc.linkup: ROUTING: removing /tmp/re1_defaultgw
May 22 14:29:02 	opnsense: /usr/local/etc/rc.linkup: ROUTING: setting IPv4 default route to 111.222.111.254
May 22 14:29:02 	opnsense: /usr/local/etc/rc.linkup: ROUTING: IPv6 default gateway set to wan
May 22 14:29:02 	opnsense: /usr/local/etc/rc.linkup: ROUTING: IPv4 default gateway set to wan
May 22 14:29:02 	opnsense: /usr/local/etc/rc.linkup: ROUTING: entering configure using 'wan'
May 22 14:28:01 	opnsense: /usr/local/etc/rc.dyndns: Dynamic DNS () There was an error trying to determine the public IP for interface - wan(re1). Probably interface is not a WAN interface.
May 22 14:28:01 	opnsense: /usr/local/etc/rc.dyndns: Aborted IPv4 detection: no address for re1
May 22 14:28:00 	opnsense: /usr/local/etc/rc.dyndns: Dynamic DNS () There was an error trying to determine the public IP for interface - wan(re1). Probably interface is not a WAN interface.
May 22 14:28:00 	opnsense: /usr/local/etc/rc.dyndns: Aborted IPv4 detection: no address for re1
May 22 14:27:43 	opnsense: /usr/local/etc/rc.linkup: HOTPLUG: Configuring interface wan
May 22 14:27:43 	opnsense: /usr/local/etc/rc.linkup: DEVD Ethernet attached event for wan
May 22 14:27:42 	kernel: re1: link state changed to UP
May 22 14:27:01 	opnsense: /usr/local/etc/rc.linkup: Clearing states to old gateway 111.222.111.254.
May 22 14:27:01 	opnsense: /usr/local/etc/rc.linkup: DEVD Ethernet detached event for wan
May 22 14:27:01 	kernel: re1: link state changed to DOWN
May 22 14:25:50 	opnsense: /index.php: Successful login for user 'root' from: 10.0.0.54
May 22 14:24:01 	opnsense: /usr/local/etc/rc.dyndns: Dynamic DNS () There was an error trying to determine the public IP for interface - wan(re1). Probably interface is not a WAN interface.
May 22 14:24:01 	opnsense: /usr/local/etc/rc.dyndns: Aborted IPv4 detection: no address for re1
May 22 14:24:00 	opnsense: /usr/local/etc/rc.dyndns: Dynamic DNS () There was an error trying to determine the public IP for interface - wan(re1). Probably interface is not a WAN interface.
May 22 14:24:00 	opnsense: /usr/local/etc/rc.dyndns: Aborted IPv4 detection: no address for re1
May 22 14:20:01 	opnsense: /usr/local/etc/rc.dyndns: Dynamic DNS () There was an error trying to determine the public IP for interface - wan(re1). Probably interface is not a WAN interface.
May 22 14:20:01 	opnsense: /usr/local/etc/rc.dyndns: Aborted IPv4 detection: no address for re1
May 22 14:20:00 	opnsense: /usr/local/etc/rc.dyndns: Dynamic DNS () There was an error trying to determine the public IP for interface - wan(re1). Probably interface is not a WAN interface.
May 22 14:20:00 	opnsense: /usr/local/etc/rc.dyndns: Aborted IPv4 detection: no address for re1
May 22 14:16:02 	opnsense: /usr/local/etc/rc.dyndns: Dynamic DNS () There was an error trying to determine the public IP for interface - wan(re1). Probably interface is not a WAN interface.
May 22 14:16:02 	opnsense: /usr/local/etc/rc.dyndns: Aborted IPv4 detection: no address for re1
May 22 14:16:00 	opnsense: /usr/local/etc/rc.dyndns: Dynamic DNS () There was an error trying to determine the public IP for interface - wan(re1). Probably interface is not a WAN interface.
May 22 14:16:00 	opnsense: /usr/local/etc/rc.dyndns: Aborted IPv4 detection: no address for re1
May 22 14:12:01 	opnsense: /usr/local/etc/rc.dyndns: Dynamic DNS () There was an error trying to determine the public IP for interface - wan(re1). Probably interface is not a WAN interface.
May 22 14:12:01 	opnsense: /usr/local/etc/rc.dyndns: Aborted IPv4 detection: no address for re1
May 22 14:12:00 	opnsense: /usr/local/etc/rc.dyndns: Dynamic DNS () There was an error trying to determine the public IP for interface - wan(re1). Probably interface is not a WAN interface.
May 22 14:12:00 	opnsense: /usr/local/etc/rc.dyndns: Aborted IPv4 detection: no address for re1
May 22 14:08:01 	opnsense: /usr/local/etc/rc.dyndns: Dynamic DNS () There was an error trying to determine the public IP for interface - wan(re1). Probably interface is not a WAN interface.
May 22 14:08:01 	opnsense: /usr/local/etc/rc.dyndns: Aborted IPv4 detection: no address for re1
May 22 14:08:00 	opnsense: /usr/local/etc/rc.dyndns: Dynamic DNS () There was an error trying to determine the public IP for interface - wan(re1). Probably interface is not a WAN interface.
May 22 14:08:00 	opnsense: /usr/local/etc/rc.dyndns: Aborted IPv4 detection: no address for re1
May 22 14:04:01 	opnsense: /usr/local/etc/rc.dyndns: Dynamic DNS () There was an error trying to determine the public IP for interface - wan(re1). Probably interface is not a WAN interface.
May 22 14:04:01 	opnsense: /usr/local/etc/rc.dyndns: Aborted IPv4 detection: no address for re1
May 22 14:04:00 	opnsense: /usr/local/etc/rc.dyndns: Dynamic DNS () There was an error trying to determine the public IP for interface - wan(re1). Probably interface is not a WAN interface.
May 22 14:04:00 	opnsense: /usr/local/etc/rc.dyndns: Aborted IPv4 detection: no address for re1
May 22 14:00:01 	opnsense: /usr/local/etc/rc.dyndns: Dynamic DNS () There was an error trying to determine the public IP for interface - wan(re1). Probably interface is not a WAN interface.
May 22 14:00:01 	opnsense: /usr/local/etc/rc.dyndns: Aborted IPv4 detection: no address for re1
May 22 14:00:00 	opnsense: /usr/local/etc/rc.dyndns: Dynamic DNS () There was an error trying to determine the public IP for interface - wan(re1). Probably interface is not a WAN interface.
May 22 14:00:00 	opnsense: /usr/local/etc/rc.dyndns: Aborted IPv4 detection: no address for re1
May 22 13:56:01 	opnsense: /usr/local/etc/rc.dyndns: Dynamic DNS () There was an error trying to determine the public IP for interface - wan(re1). Probably interface is not a WAN interface.
May 22 13:56:01 	opnsense: /usr/local/etc/rc.dyndns: Aborted IPv4 detection: no address for re1
May 22 13:56:00 	opnsense: /usr/local/etc/rc.dyndns: Dynamic DNS () There was an error trying to determine the public IP for interface - wan(re1). Probably interface is not a WAN interface.
May 22 13:56:00 	opnsense: /usr/local/etc/rc.dyndns: Aborted IPv4 detection: no address for re1
May 22 13:54:56 	opnsense: /usr/local/etc/rc.dyndns: Dynamic DNS () There was an error trying to determine the public IP for interface - wan(re1). Probably interface is not a WAN interface.
May 22 13:54:56 	opnsense: /usr/local/etc/rc.dyndns: Aborted IPv4 detection: no address for re1
May 22 13:54:54 	opnsense: /usr/local/etc/rc.dyndns: Dynamic DNS () There was an error trying to determine the public IP for interface - wan(re1). Probably interface is not a WAN interface.
May 22 13:54:54 	opnsense: /usr/local/etc/rc.dyndns: Aborted IPv4 detection: no address for re1
May 22 13:54:52 	opnsense: /usr/local/etc/rc.linkup: ROUTING: skipping IPv6 default route
May 22 13:54:52 	opnsense: /usr/local/etc/rc.linkup: The command '/sbin/route add -'inet' default '111.222.111.254'' returned exit code '1', the output was 'route: writing to routing socket: Network is unreachable add net default: gateway 111.222.111.254 fib 0: Network is unreachable'
May 22 13:54:52 	opnsense: /usr/local/etc/rc.linkup: ROUTING: creating /tmp/re1_defaultgw using '111.222.111.254'
May 22 13:54:52 	opnsense: /usr/local/etc/rc.linkup: ROUTING: setting IPv4 default route to 111.222.111.254
May 22 13:54:52 	opnsense: /usr/local/etc/rc.linkup: ROUTING: IPv6 default gateway set to wan
May 22 13:54:52 	opnsense: /usr/local/etc/rc.linkup: ROUTING: IPv4 default gateway set to wan
May 22 13:54:52 	opnsense: /usr/local/etc/rc.linkup: ROUTING: entering configure using 'wan'
May 22 13:53:30 	opnsense: /usr/local/etc/rc.linkup: HOTPLUG: Configuring interface wan
May 22 13:53:30 	opnsense: /usr/local/etc/rc.linkup: DEVD Ethernet attached event for wan
May 22 13:53:30 	kernel: re1: link state changed to UP
May 22 13:53:02 	opnsense: /usr/local/etc/rc.dyndns: Dynamic DNS () There was an error trying to determine the public IP for interface - wan(re1). Probably interface is not a WAN interface.
May 22 13:53:02 	opnsense: /usr/local/etc/rc.dyndns: Aborted IPv4 detection: no address for re1
May 22 13:53:00 	opnsense: /usr/local/etc/rc.dyndns: Curl error occurred: bind failed with errno 47: Address family not supported by protocol family
May 22 13:52:54 	opnsense: /usr/local/etc/rc.linkup: Clearing states to old gateway 111.222.111.254.
May 22 13:52:54 	opnsense: /usr/local/etc/rc.linkup: DEVD Ethernet detached event for wan
May 22 13:52:54 	kernel: re1: link state changed to DOWN
May 22 13:52:14 	opnsense: /usr/local/etc/rc.dyndns: Curl error occurred: bind failed with errno 47: Address family not supported by protocol family
May 22 13:52:12 	lost sys.stderr
May 22 13:52:12 	sys.excepthook is missing
May 22 13:52:12 	close failed in file object destructor:
May 22 13:52:12 	configd_ctl.py: error in configd communication Traceback (most recent call last): File "/usr/local/opnsense/service/configd_ctl.py", line 65, in exec_config_cmd line = sock.recv(65536) timeout: timed out
May 22 13:51:13 	opnsense: /usr/local/etc/rc.dyndns: Curl error occurred: bind failed with errno 47: Address family not supported by protocol family
May 22 13:48:02 	opnsense: /usr/local/etc/rc.dyndns: Dynamic DNS: (Success) IP Address Updated Successfully!
May 22 13:48:02 	opnsense: /usr/local/etc/rc.dyndns: Dynamic DNS: updating cache file /var/cache/dyndns_wan__1.cache: 111.222.111.94
May 22 13:48:00 	opnsense: /usr/local/etc/rc.dyndns: Dynamic DNS: (Success) IP Address Updated Successfully!
May 22 13:48:00 	opnsense: /usr/local/etc/rc.dyndns: Dynamic DNS: updating cache file /var/cache/dyndns_wan__0.cache: 111.222.111.94

17.7 Legacy Series / HAProxy loses function after WAN IP-address change

« on: December 04, 2017, 12:20:46 am »

Hi,

i am using the current 17.7.8 release and have some problems with haproxy, which is used to access some surveillance cameras over https (port 7443). because i don't want ssl warnings due to the self-signed certificate of the surveillance-server, i use haproxy with the letsencrypt certificate of the opnsense itself to access the video system. my ISP resets my internet connection (PPPoE) every 24 hours, everytime a new ip address is assigned, so i use an own dyndns-service (updates every minute "opnsense.example.tld"). the both needed frontends are listening to opnsense.example.com:7443 and :7446, which is working fine until the wan ip address changes. after then, the video services are not reachable (timeout) until haproxy is disabled and enabled again (restart via lobby does not work), which in my opinion is caused by not automatically updating the frontend listener address with the newly assigned ip on ip change.

is there any way to fix or circumvent that ?

Pages: [1] 2