Topics

1

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


2

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?

3

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 ?

4

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 ?

5

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 ?

6

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


7

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 ?

8

German - Deutsch / Wie am besten potentiellen Bug finden ?

« on: October 17, 2017, 12:36:31 pm »

Hallo,

seit etwas längerer Zeit habe ich mit einer meiner OPNSenses kleine Meinungsverschiedenheiten, die sich bislang nicht lösen ließen und ziemlich schwer aufzuspüren sind. Ich vermute entweder einen Bug direkt in OPNSense oder einen Bug in Kombination mit der verwendeten Hardware. Da inzwischen ein von Monaten bestelltes LTE-Modem eingetroffen ist, wollte ich erneut die Inbetriebnahme von Failover-Multiwan ausprobieren, und prompt meldete sich der Bug wieder zur Stelle. Leider sind die Logs erstaunlich unaussagekräftig, deswegen wollte ich fragen ob es bessere Möglichkeiten zum Debuggen gibt, das ich verwertbare Protokolle für einen anständigen Bugreport habe.

Konkret geht es um folgendes Setup und Problem:

SuperMicro A1SRM-2558F, Intel Atom C2558
2x 4GB ECC RAM
2x Samsung 850 Evo SSD
4x Intel GbE LAN onBoard
aktuellste OPNSense-Version

Die Interfaces sind wie folgt angelegt:

igb0:  pppoe0 über Draytek Vigor 130 (VDSL2+)
         opt1 (10.0.200.10) für Zugriff auf DSL Modem
igb1:  igb1,lan (10.0.0.1/22) an 1. Mikrotik CRS125G-24-RM
igb2:  igb2,unkonfiguriert an 3. Mikrotik CRS125G-24-RM
         opt2, vlan20 (10.0.24.1/21)
         opt3, vlan40 (10.0.40.1/24)
         opt6, vlan10 (10.0.10.1/24)
         opt7, vlan30 (10.0.36.1/23)
igb3:  unkonfiguriert

Bis an diesen Punkt funktioniert alles einwandfrei. Nun möchte ich seit Juni das Setup um ein Multiwan-Failover über LTE ergänzen, und an diesem Punkt geht dann alles schief. Die erste Variante war per ppp oder ncm/qpi per USB-LTE-Modem. Hier trat damals der Bug auf, deswegen verwarf ich das ganze und versuchte es mit einem TP-Link LTE Router an igb3. Ebenfalls selber Bug. Daraufhin bestellte ich das bis dato nicht lieferbaren Mikrotik WAP LTE Kit, um eine etwas handfestere nicht fricklige Lösung zu haben. Das LTE Kit kam jetzt am Montag, deswegen wurde es gleich ausprobiert, und zonk: Bug!

Das Problem habe ich bisher noch nicht beschrieben, es äußert sich wie folgt:

Irgendwo zwischen Anlegen des Interfaces und dem Konfigurieren von MultiWAN wird die Weboberfläche unresponsiv, das System beginnt zu hängen und letztendlich kracht das Netzwerk zusammen: WAN geht offline, die VLANs funktionieren nur noch teilweise und verlieren teilweise ihre Konfiguration (werden beim SSH Login entweder ohne IP oder gar nicht mehr angezeigt), Internetzugang funktioniert nur noch teilweise. Externe Erreichbarkeit (SSH, HTTPS, IPSEC) ist nicht mehr gegeben. Dies lässt sich auch durch einen Neustart der OPNSense nicht beheben, nur noch durch eine Wiederherstellung der alten Konfiguration über die lokale Konsole. In den Logs konnte ich bisher nicht verwertbares finden. Beim Hochfahren bleibt die OPNSense ca. 1-2 Minuten bei "configuring wan interfaces..." hängen und kann die VLANs offensichtlich nicht ordentlich konfigurieren. Das Problem ist immer reproduzierbar, auch bei einer komplett frisch installierten OPNSense. Ich habe alles probiert, auch bei kompletter Konfiguration ohne Webinterface an der lokalen Konsole tritt das Problem auf. Erstaunlicherweise kommt es ab und zu nach einer langen Zeitspanne wieder zu einem "normalen" Betriebszustand, das System ging gestern aufgrund des Bugs gegen 23.30 Uhr offline und war gegen 09.30 Uhr heute morgen ohne Eingriff wieder online.

Ich vermute entweder einen Bug in OPNSense, configd, oder im Zusammenspiel zwischen FreeBSD und der Hardware (Intel i354 quad-GbE).

Ich möchte einen neuen Versuch mit einer Neuinstallation von OPNSense 17.7 starten, aber gleichzeitig auch verwertbare Daten sammeln für einen Bugreport - wie stelle ich das am besten an ?

9

German - Deutsch / IPv6 bei Kabel Deutschland

« on: February 09, 2017, 04:44:11 pm »

Hallo,

ich versuche IPv6 bei Kabel Deutschland zum laufen zu bringen. Ich habe noch das Cisco EPC3212 Modem, das heißt ich bekomme einen echten DualStack mit einem leider nur /64er Prefix.

Die OPNsense habe ich wie folgt konfiguriert:

WAN Interface:
IPv6 Configuration Type: DHCPv6 (SLAAC geht nicht)

DHCPv6 client configuration (basic):
Use IPv4 connectivity: no
Request only a IPv6 prefix: no
directly send solicit: no
Prefix Delegation Size: 64
Send IPv6 Prefix Hint: y

LAN Interface:
IPv6 Interface: WAN
IPv6 Prefix ID: 0

In der Übersicht sehe ich auch, das dem WAN Interface eine v6-IP zugeteilt wurde mit /128, und dem LAN Interface eine andere v6-IP mit /64er Prefix. Die Clients bekommen jedoch öfters keine v6 zugewiesen (unter Services -> DHCPv6 sind alle Einstellungen mangels statischer v6 gesperrt). Manchmal dauert es auch bis zu 15 Minuten, bis eine neue IPv6 zugewiesen wird. In dieser Zeit gehen sämtliche DualStack-Dienste (google z.B.) nur extrem langsam, da scheinbar per IPv6 nicht korrekt erreichbar (timeout). Ganz schlimm tritt das Problem nach einem Neustart der OPNsense auf, dort wird dann auch öfters dem WAN interface keine IPv6 zugewiesen, erst irgendwann.

Stimmt hier irgendwo etwas an den Einstellungen nicht, oder braucht es einen speziellen Trick für Kabel Deutschland ?

Die Logfiles sind soweit unauffällig, nur ab und zu taucht dieser hier auf:

opnsense: /usr/local/etc/rc.filter_configure_sync: Could not find IPv6 gateway for interface(wan).

10

17.1 Legacy Series / IPSEC IKEv2 failing after successful connection

« on: February 08, 2017, 10:48:20 pm »

hello,

i recently switched from pfSense to OPNsense 17.1. the machine is a Intel D510MO with 3x GbE LAN (1x onboard, 1x DualPort Intel GbE PCI NIC) on a 100/10 MBit/s dial-up connection with dynamic IP. so far everything is fine, but i can't get IPSec working again. Basically, i used the "official" pfsense wiki for setup, which was working fine on pfSense itself. Now, with OPNSense after the successfull EAP auth my connection is dropped, and i can't figure out why this happens.

here the log (bottom-up):

Code: [Select]

Feb 8 22:34:31 charon: 09[ENC] insert payload NOTIFY into encrypted payload
Feb 8 22:34:31 charon: 09[ENC] generating IKE_AUTH response 5 [ N(AUTH_FAILED) ]
Feb 8 22:34:31 charon: 09[ENC] added payload of type NOTIFY to message
Feb 8 22:34:31 charon: 09[ENC] order payloads in message
Feb 8 22:34:31 charon: 09[ENC] added payload of type NOTIFY to message
Feb 8 22:34:31 charon: 09[CFG] no alternative config found
Feb 8 22:34:31 charon: 09[CFG] selected peer config 'con1' inacceptable: non-matching authentication done
Feb 8 22:34:31 charon: 09[CFG] constraint check failed: peer not authenticated by CA 'C=DE, ST=Bavaria, L=XXX, O=YYY, E=null@host.tld, CN=some.domain.tld'
Feb 8 22:34:31 charon: 09[IKE] authentication of 'nullinger@otherdomain.tld' with EAP successful
so, somehow it looks like some problem with the CA, but it looks fine for me. any ideas ? the CN is matching the DynDNS-name, and for the client cert both the CN and the "DNS" alternative Name is set to the DynDNS-name.