Exakt zu jeder vollen Stunde: LOCAL0 Fehler VPN: Error for peer VPN_TR_MAC: IFC-I-No-channel-available

[tom63]

ich bekomme im syslog exakt zu jeder vollen stunde diesen fehler: LOCAL0 Fehler VPN: Error for peer VPN_TR_MAC: IFC-I-No-channel-available
16:00:00 17:00:00 18:00:00 ...

woran kann das liegen? diese verbindung ist auch gerade gar nicht benutzt. und in der cron tabelle ist ein einziger eintrag und der ist sogar deaktiviert.

gruss
tom

[5624]

Der Fehler tritt auf, wenn durch Traffic an die/eine IP-Adresse auf der anderen Seite des Tunnels die Verbindung aufgebaut werden soll, aber nicht werden kann, weil keine IP-Adresse bekannt ist. Häufig kommt der Fehler nicht alleine, sondern meist ist noch mindestens ein weiterer Hinweis dabei.

Kannst du ignorieren, der Fehler besagt einfach nur aus, dass keine Verbindung da ist.

[tom63]

hallo 5624,

dankeschoen fuer die schnelle antwort

ok. das komische ist halt dass ich eine zweite exakt gleiche vpn einwahlverbindung auch fuer einen mac habe und da kommt der fehler nicht. allerdings war die andere seit monaten nicht mehr genutzt worden und die wo der fehler kommt aber erst gestern und da hat sie einwandfrei funktioniert. und komisch ist auch dieses auf die sekunde alle stunde?

ich frag mich halt ob es an meinem update von 10.12 auf 10.40 liegen koennte. oder an meinem rumgemurkse in der firewall und dem pi-hole als dns?

verwirrter gruss
tom

[Jirka]

Hallo zusammen,

im Eingangsposting feht der Hinweis, um was es sich für eine VPN-Verbindung handelt, aber es wird dann offensichtlich, dass es sich um eine VPN-Clientverbindung handelt, wie 5624 ja auch schon beschrieben hat. Die kann logischerweise nicht aufgebaut werden.
Die Frage, die man sich jetzt stellen kann ist, wer versucht denn jetzt (stündlich) die IP-Adresse zu kontaktieren. Das kann man sicherlich tracen und dann abstellen. Wenn man derartige Meldungen für immer los sein möchte, sollte man sich eine Firewall-Regel erstellen, die Traffic an diese VPN-Gegenstelle verwirft, solange die Verbindung nicht aufgebaut ist. So richtet man ordnungsgemäß eine VPN-Clientverbindung ein.
Name: VPN_VERBINDUNGSAUFBAU_ABWARTEN
x Diese Regel ist für die Firewall aktiv
x Diese Regel hält die Verbindungszustände nach (default)
Prio: ausreichend hoch bis sehr hoch ansiedeln
Paket-Aktion: Verwerfen, Aktion nur: x wenn Verbindung nicht besteht u.: x für VPN-Route
Stationen: Verbindungs-Ziel: VPN-Gegenstelle oder mehrere VPN-Gegenstellen (Achtung, Aufbaurichtung/Haltezeit beachten) oder Objekt Private_IPs anlegen

Übergangsweise kann man auch (zusätzlich) x E-Mail-Nachricht senden bei Aktionen ankreuzen oder x SNMP/LANmonitor, wenn man schauen möchte, wer oder was da Pakete zu der IP-Adresse schicken möchte.

Das Problem sollte übrigens nur auftreten, wenn die Ziel-IP-Adresse auch in der Routing-Tabelle auftaucht, also z. B. bei einer VPN-Client-Verbindung mit fester IP-Adresse.

Viele Grüße,
Jirka

[5624]

Ich hab von den Meldungen hunderte am Tag. Die sind unwichtig.

Ich weiß nicht, wie du deine VPN-Verbindungen aufgebaut hast, aber es reicht nur ein Paket an die IP-Adresse auf der entfernten Seite. Egal ob ein Ping oder was auch immer. Irgendwo eine geplante Aufgabe oder irgendein Programm, was die IP-Adresse hat. Kann man mit einer Firewallregel blocken, aber wie gesagt, absolut unwichtig die Meldung in deinem Fall.

Um herauszufinden, warum die Verbindung aufgebaut wird, könnte man jetzt ein IP-Router-Trace laufen lassen, aber der zeitliche Aufwand wäre höher, als die Meldung es wert wäre.

[tom63]

Ich hab von den Meldungen hunderte am Tag. Die sind unwichtig.

Ich weiß nicht, wie du deine VPN-Verbindungen aufgebaut hast, aber es reicht nur ein Paket an die IP-Adresse auf der entfernten Seite. Egal ob ein Ping oder was auch immer. Irgendwo eine geplante Aufgabe oder irgendein Programm, was die IP-Adresse hat. Kann man mit einer Firewallregel blocken, aber wie gesagt, absolut unwichtig die Meldung in deinem Fall.

Um herauszufinden, warum die Verbindung aufgebaut wird, könnte man jetzt ein IP-Router-Trace laufen lassen, aber der zeitliche Aufwand wäre höher, als die Meldung es wert wäre.

auf jeden fall schon mal beruhigend jetzt von dir zu wissen dass es nix wichtiges ist.

so ist die adresse festgelegt - war damals mit einem der lancom wizzards/anleitungen fuer die ike/ipsec vpn verbindung zu mobilen mac oder ios geraeten angelegt worden.

[tom63]

Die Frage, die man sich jetzt stellen kann ist, wer versucht denn jetzt (stündlich) die IP-Adresse zu kontaktieren. Das kann man sicherlich tracen und dann abstellen.

hallo jirka,

genau - stuendlich und immer zur vollen stunde - ein geist. ich probier jetzt mal den trace auf ip-router wie es 5624 vorgeschlagen hatte. nicht weil es sein muss - aber weil ich noch nie einen 'trace' gemacht hab

Wenn man derartige Meldungen für immer los sein möchte, sollte man sich eine Firewall-Regel erstellen, die Traffic an diese VPN-Gegenstelle verwirft, solange die Verbindung nicht aufgebaut ist. So richtet man ordnungsgemäß eine VPN-Clientverbindung ein.
Name: VPN_VERBINDUNGSAUFBAU_ABWARTEN
x Diese Regel ist für die Firewall aktiv
x Diese Regel hält die Verbindungszustände nach (default)
Prio: ausreichend hoch bis sehr hoch ansiedeln
Paket-Aktion: Verwerfen, Aktion nur: x wenn Verbindung nicht besteht u.: x für VPN-Route
Stationen: Verbindungs-Ziel: VPN-Gegenstelle oder mehrere VPN-Gegenstellen (Achtung, Aufbaurichtung/Haltezeit beachten) oder Objekt Private_IPs anlegen

Übergangsweise kann man auch (zusätzlich) x E-Mail-Nachricht senden bei Aktionen ankreuzen oder x SNMP/LANmonitor, wenn man schauen möchte, wer oder was da Pakete zu der IP-Adresse schicken möchte.

Das Problem sollte übrigens nur auftreten, wenn die Ziel-IP-Adresse auch in der Routing-Tabelle auftaucht, also z. B. bei einer VPN-Client-Verbindung mit fester IP-Adresse.

super - dankeschoen! dann habe ich gleich eine anfaengergerechte vorlage falls ich es mit einer firewallregel wegmachen will.

netter gruss
tom

p.s. du erinnerst dich sicher nicht mehr aber du hattest mir auch schon vor ein paar jahren einmal sehr mir der von der telekom erzwungenen umstellung von isdn auf sip geholfen. und da auch mit dem fax-betrieb. laeuft bis heute alles ganz einwandfrei seitdem.

[tom63]

war nichts drinnen im ip-router trace zur fraglichen uhrzeit mit der ip-adresse oder dem vpn-namen. im syslog war der eintrag dann trotzdem wieder.

und dass dass mein tracen funktioniert hab ich danach noch kurz probiert indem ich mit dem iphone kurz das vpn ueber mobilfunk eingeschaltet habe - und sofort waren hunderte zeilen mit der gesuchten ip und dem vpn-namen im trace.