LANCOM VPN Client wird durch IDS nach einer Weile blockiert

[RaBu78]

Moin zusammen,

wir habe hier ein 1906VA mit der FW: 10.050.0953RU8 am laufen. Unser Netz ist 10.0.0.0/16 und wir vergeben unseren VPN-Teilnehmern Adresse von 10.0.27.1 - 10.0.27.200.

Wir haben aktuell das Problem (wohl schon seit längerem), dass einige VPN Teilnehmer nach 5-6 Stunden arbeiten auf einmal geblockt werden vom IDS. Die VPN Verbindung steht aber kein Datenverkehr zwischen VPN-Client (LANCOM Advanced Client) und Router scheint mehr möglich. Der Mitarbeiter wählt sich dann aus und einmal erneut ein und dann kann er wieder für 5-6 Stunden arbeiten (sofern er nicht vorher Feierabend macht ). In dem Fall ist er anscheinend nicht geblockt weil er eine neue IP (10.0.27.x) bekommt.

Im Syslog sehe ich dann sowas:

10.0.1.91 - Der Router
10.0.27.1 - Der VPN Client

Code: Alles auswählen

2022-11-23 11:56:04	Local3.Alert	10.0.1.91	PACKET_ALERT: Dst: 45.11.129.28:443, Src: 10.0.27.1:61862 {VPN_CLIENT_123} (TCP): intrusion detection
2022-11-23 11:56:04	Local3.Info		10.0.1.91	PACKET_INFO: matched filter: intruder detection 
2022-11-23 11:56:04	Local3.Info		10.0.1.91	PACKET_INFO: filter info: packet received from invalid interface VPN_CLIENT_123
2022-11-23 11:56:04	Local3.Info		10.0.1.91	PACKET_INFO: actions: drop; send syslog message; send SNMP trap
2022-11-23 11:57:05	Local3.Alert	10.0.1.91	PACKET_ALERT: Dst: 10.0.1.92:53, Src: 10.0.27.1:53701 {VPN_CLIENT_123} (UDP): intrusion detection
2022-11-23 11:57:05	Local3.Info		10.0.1.91	PACKET_INFO: matched filter: intruder detection 
2022-11-23 11:57:05	Local3.Info		10.0.1.91	PACKET_INFO: filter info: packet received from invalid interface VPN_CLIENT_123
2022-11-23 11:57:05	Local3.Info		10.0.1.91	PACKET_INFO: actions: drop; send syslog message; send SNMP trap
2022-11-23 11:57:33	Local3.Alert	10.0.1.91	PACKET_ALERT: Dst: 85.16.66.99:123 {router}, Src: 147.203.255.20:51932 (UDP): connection refused
2022-11-23 11:58:06	Local3.Alert	10.0.1.91	PACKET_ALERT: Dst: 149.112.112.112:443, Src: 10.0.27.1:50752 {VPN_CLIENT_123} (TCP): intrusion detection
2022-11-23 11:58:06	Local3.Info		10.0.1.91	PACKET_INFO: matched filter: intruder detection 
2022-11-23 11:58:06	Local3.Info		10.0.1.91	PACKET_INFO: filter info: packet received from invalid interface VPN_CLIENT_123
2022-11-23 11:58:06	Local3.Info		10.0.1.91	PACKET_INFO: actions: drop; send syslog message; send SNMP trap
2022-11-23 11:59:07	Local3.Alert	10.0.1.91	PACKET_ALERT: Dst: 45.11.129.27:443, Src: 10.0.27.1:51033 {VPN_CLIENT_123} (TCP): intrusion detection
2022-11-23 11:59:07	Local3.Info		10.0.1.91	PACKET_INFO: matched filter: intruder detection 
2022-11-23 11:59:07	Local3.Info		10.0.1.91	PACKET_INFO: filter info: packet received from invalid interface VPN_CLIENT_123
2022-11-23 11:59:07	Local3.Info		10.0.1.91	PACKET_INFO: actions: drop; send syslog message; send SNMP trap
2022-11-23 12:00:09	Local3.Alert	10.0.1.91	PACKET_ALERT: Dst: 10.0.1.92:53, Src: 10.0.27.1:63456 {VPN_CLIENT_123} (UDP): intrusion detection
2022-11-23 12:00:09	Local3.Info		10.0.1.91	PACKET_INFO: matched filter: intruder detection 
2022-11-23 12:00:09	Local3.Info		10.0.1.91	PACKET_INFO: filter info: packet received from invalid interface VPN_CLIENT_123
2022-11-23 12:01:09	Local3.Alert	10.0.1.91	PACKET_ALERT: Dst: 45.11.129.64:443, Src: 10.0.27.1:51610 {VPN_CLIENT_123} (TCP): intrusion detection
2022-11-23 12:01:09	Local3.Info		10.0.1.91	PACKET_INFO: matched filter: intruder detection 
2022-11-23 12:01:09	Local3.Info		10.0.1.91	PACKET_INFO: filter info: packet received from invalid interface VPN_CLIENT_123
2022-11-23 12:01:09	Local3.Info		10.0.1.91	PACKET_INFO: actions: drop; send syslog message; send SNMP trap
2022-11-23 12:01:12	Auth.Info		10.0.1.91	CONN-LOGIN_INFO: User VPN_CLIENT_123 logged out
2022-11-23 12:01:22	Auth.Notice		10.0.1.91	CONN-LOGIN_INFO: User VPN_CLIENT_123 successfully logged in

Was im Syslog bei der IDS auffällig ist dass ein IDS erkannt wird wenn der VPN-Client (10.0.27.1:53701) auf unseren DNS-Server (10.0.1.92:53 - der im bekannten Netz hängt) zugreift. Warum schlägt hier die IDS an?

Die IDS Einträge kommen auch nicht flut-artig sondern wenige pro Minute.

Wir habe seit mehreren Tagen schon probiert Stufenweise die "Maximalzahl der Port-Anfragen" auf den Wert von 500, 2000, 4000 und jetzt auf den Max.-Wert von 9999 gesetzt. Es verhält sich aber immer gleich, d.h. die gleichen (aktuell 4 bekannte) VPN-Clients haben die gleichen Verbindungsprobleme im ungefähr gleichen Zeitintervall, d.h. so nach 5-6 Stunden.

Hat jemand ein Tipp für mich was das sein könnte bzw. warum die IDS hier anschlägt?

Gruß Rainer

[backslash]

Hi RaBu78

Hat jemand ein Tipp für mich was das sein könnte bzw. warum die IDS hier anschlägt?

sagen, was bei dir los ist, kann ich nicht, ich kann nur Hinweise zum Debugging geben:

Das IDS schlägt dann an, wenn das Paket über ein Interface empfangen wurde, an das KEINE Route zur Quell-Adresse gebunden ist...

Das bedeutet, daß in dem Moment, in dem das passiert, die Route zur Quell-Adresse des Pakets (im Log 10.0.27.1) nicht (mehr) auf das Interface zeigt, über das das Paket empfanegn wurde (im Log VPN_CLIENT_123).

Das kannst du auf dem CLI über das Kommando "show ipv4-fib" prüfen. Das Kommando gibt die die interne Darstellung der Routing-Tabelle (sortiert nach Routing-Tags) aus. Wenn es keine Route zur 10.0.27.1 gibt, die auf VPN_CLIENT_123 zeigt, dann schlägt das IDS an...

Warum bei dir offenbar nach 6 Stunden die Route "rausfällt" kann ich dir allerdings nicht sagen...

Weist du die Adressen statisch zu oder nutzt du einen Pool (für IKEv1 wäre das der globale Adressßpool unter IPv4 -> Adressen -> Adressbereich für Einwahlzugänge, für IKEv2 ein unter VPN -> IKEv2/IPSec -> Adressen für Einwahlzugänge -> IPv4-Adresses definierter Pool)?

Am einfachsten kannst du das vermutlich umgehen, indem für die VPN-Clients statische Einträge in der Routing-Tabelle machst...


Gruß
Backslash

[GrandDixence]

Für Einwahlverbindungen (RAS) wird üblicherweise IKE-CFG eingesetzt und dabei werden die für den VPN-Client erforderlichen Routingtabelleneinträge vollautomatisch erstellt und entfernt. Siehe dazu:
fragen-zum-thema-vpn-f14/windows-10-mit ... ml#p101697

Der Routingtabelleneintrag für den VPN-Client fliegt logischerweise aus der Routingtabelle des LANCOM-Routers, wenn der VPN-Server per DPD (Dead peer detection) feststellt, dass der VPN-Client nicht mehr erreichbar ist. Ursache der (DPD-)Probleme ist wahrscheinlich ein nicht funktionierendes Rekeying. Siehe dazu:
fragen-zum-thema-vpn-f14/ikev2-vpn-tunn ... ml#p103501

fragen-zum-thema-vpn-f14/vpn-via-androi ... tml#p97795

[RaBu78]

Moin,

@Backslash: Es scheint demnach so zu sein, dass die IDS eine Folge des eigentlichen Problems sind und die nicht Ursache. Das deckt sich dann auch damit, dass egal was für ein Wert ich bei der IDS einstelle es keinen unterschied gibt. Wir verwenden aktuell noch IKv1 mit PSK und das sowohl mit Shrew als auch mit dem LANCOM VPN Client. Aktuell bekomme ich nur negative Rückmeldungen von Leuten mit dem LANCOM Client. Die VPN Zugänge sind schlicht via Assistent eingerichtet und es gibt nur dynamische Einträge in der Routing-Tabelle für die LANCOM VPN Clients. Bei Shrew sind diese hingegen statisch.

Ich schaue mir morgen mal das Log vom LANCOM VPN Client an. Das scheint ja recht ausführlich zu sein.

@GrandDixence: Danke für die Infos. Noch einige Fragen:

1. Gibt es denn evtl. bekannte Probleme mit dem Rekeying und dem LAC? Anscheinend tritt das Problem nicht bei allen LAC-Nutzern auf.
2. Kannst du mir sagen wo ich die Schlüsselmateriallebensdauer des Steuerkanals für IKEv1 reduzieren kann um das Rekeying zu testen?
3. Würde es helfen die DPD zu deaktivieren? Edit: Bei den Shrew-Clients ist es bereits deaktiviert.

Gruß RaBu

[GrandDixence]

1.) Rekeying-Probleme gehören zu den häufigsten Konfigurationsfehlern im VPN-Bereich.
2.) IKEv1 ist abzulösen durch IKEv2. Wir schreiben das Jahr 2022!! => Siehe die bereits verlinkte VPN-Anleitungssammlung. Dort ist auch die Konfiguration der Schlüsselmateriallebensdauer ersichtlich. Die aktuell laufende Schlüsselmateriallebensdauer ist im LANCOM-Router irgendwo unter LCOS-Menübaum > Status > VPN ersichtlich.
3.) DPD muss zwingend auf dem VPN-Server aktiv sein. Sonst laufen die verfügbaren VPN-Lizenzen aus. Generell ist der Einsatz von DPD zu empfehlen. Somit sollte DPD auch auf dem VPN-Client (nach Möglichkeit) eingesetzt werden, um Trennungen des VPN-Tunnels möglichst zeitnah zu erkennen.

[RaBu78]

Moin GrandDixence,

danke für die Infos.

IKv1 durch IKEv2 abzulösen steht bei uns auf der Agenda und auch nicht soweit nach hinten . Evtl. pusht dieses Thema das ja auch.

Darf ich nochmal fragen was du genau meinst mit Konfigurationsfehler beim Rekeying. Wir haben an der Router-Konfiguration an den Werten bzgl. VPN / IKE nichts geändert. Sind alles Standardeinstellungen von LANCOM. Wir haben den Client mittels LANCOM Assistenten eingerichtet - Profil im LAC importiert und das wars.

Wo könnten den Konfigurationsfehler vorliegen, also wonach muss ich gucken?

Gruß RaBu

[RaBu78]

Moin,

heute habe ich es mal genauer dokumentiert:

Ein VPN Client hat sich um 06:44:32 eingewählt und die Verbindungsprobleme (erster IDS Eintrag) um 12:23:00 gehabt (20308 Sekunden)

Ich habe um 10:43 mir Screenshots gemacht von (Zu diesem Zeitpunkt) gab es keine Probleme:

=> /Status/IP-Router/Act.-IPv4-Routing-Tab./ => Routing-Tabellen Eintrag vom Client war vorhanden
=> /status/vpn/esp
=> /status/vpn/ike

10_34_ESP+IKE.jpg

Ich habe nach 12:23 ebenfalls Screenshots gemacht als das Problem anstatt, d.h. die VPN-Verbindung war aufgebaut aber keine Daten liefen durch den Tunnel:

=> /Status/IP-Router/Act.-IPv4-Routing-Tab./ => Routing-Tabellen Eintrag vom Client war nicht mehr vorhanden (das erklärt jetzt den IDS Eintrag)
=> /status/vpn/esp
=> /status/vpn/ike

NACH_12_23_ESP+IKE.jpg

Zudem habe ich mir das Log vom LANCOM Client abgezogen:

Code: Alles auswählen

24.11.2022 12:23:00 - Ike: RekeyEx-Outgoing connect request AGGRESSIVE mode - gateway=xx.xx.xx.99 : COMPANY
24.11.2022 12:23:00 - Ike: ConRef=36, XMIT_MSG1_AGGRESSIVE, name=COMPANY, vpngw=xx.xx.xx.99:4500
24.11.2022 12:23:00 - ike_phase1:send_id:ID_USER_FQDN:pid=0,port=0,XXXXXX_L@intern
24.11.2022 12:23:00 - Ike: ConRef=36, Send NAT-D vendor ID,remprt=4500
24.11.2022 12:23:00 - Ike: ConRef=36, RECV_MSG2_AGGRESSIVE, adapterindex=203,name=COMPANY, remote ip:port=xx.xx.xx.99:4500,local ip:port=192.168.178.25:10954
24.11.2022 12:23:00 - Ike: IKE phase I: Setting LifeTime to 28800 seconds
24.11.2022 12:23:00 - Ike: IkeSa1 negotiated with the following properties -
24.11.2022 12:23:00 -   Authentication=PRE_SHARED_KEY,Encryption=AES,Hash=SHA,DHGroup=2,KeyLen=256
24.11.2022 12:23:00 - Ike: COMPANY ->Support for NAT-T version - 9
24.11.2022 12:23:00 - Ike: Turning on NATD mode - COMPANY - 1
24.11.2022 12:23:00 - Ike: ike_phase1:recv_id:ID_USER_FQDN:pid=0,port=0,XXXXXX_L@intern
24.11.2022 12:23:00 - Ike: ConRef=36, XMIT_MSG3_AGGRESSIVE, name=COMPANY, vpngw=xx.xx.xx.99:4500
24.11.2022 12:23:00 - Ike: IkeSa1 negotiated with the following properties -
24.11.2022 12:23:00 -   Authentication=PRE_SHARED_KEY,Encryption=AES,Hash=SHA,DHGroup=2,KeyLen=256
24.11.2022 12:23:00 - Ike: Turning on DPD mode - COMPANY
24.11.2022 12:23:00 - Ike: phase1:name(COMPANY) - connected
24.11.2022 12:23:00 - SUCCESS: IKE phase 1 ready
24.11.2022 12:23:00 - IPSec: Phase1 is Ready,AdapterIndex=203,IkeIndex=35,LocTepIpAdr=192.168.178.25,AltRekey=1
24.11.2022 12:23:00 - IPSec: Quick Mode is Ready: IkeIndex=35,VpnSrcPort=10954
24.11.2022 12:23:00 - IPSec: Assigned IP Address:IPv4=10.0.27.81,IPv6=0.0.0.0
24.11.2022 12:23:00 - IPSec: Assigned IP Network Mask:IPv4=255.255.255.0,IPv6=255.255.255.255
24.11.2022 12:23:00 - IPSec: Gateway IP Address:IPv4=0.0.0.0,IPv6=0.0.0.0
24.11.2022 12:23:00 - IPSec: Primary DNS Server: 10.0.1.92
24.11.2022 12:23:00 - IPSec: Secondary DNS Server: 0.0.0.0
24.11.2022 12:23:00 - IPSec: Primary WINS Server: 10.0.1.92
24.11.2022 12:23:00 - IPSec: Secondary WINS Server: 0.0.0.0
24.11.2022 12:23:00 - IPSec: Primary NCP SEM Server: 0.0.0.0
24.11.2022 12:23:00 - IPSec: Secondary NCP SEM Server: 0.0.0.0
24.11.2022 12:23:00 - IPSec: Primary DNS6 Server: 0.0.0.0
24.11.2022 12:23:00 - IPSec: Secondary DNS6 Server: 0.0.0.0
24.11.2022 12:23:00 - IPSec: Primary NCP SEM6 Server: 0.0.0.0
24.11.2022 12:23:00 - IPSec: Secondary NCP SEM6 Server: 0.0.0.0
24.11.2022 12:23:04 - IPSec,ConRef=35: rekeying due to LifeTime or LifeKb, roamingcon=1,spi=d2beb0b4
24.11.2022 12:23:04 - IkeQuick: ike_phase2:send_id1:ID_IPV4_ADDR:pid=0,port=0,10.0.27.81
24.11.2022 12:23:04 - IkeQuick: ike_phase2:send_id2:ID_IPV4_ADDR_SUBNET:pid=0,port=0,0.0.0.0 - 0.0.0.0
24.11.2022 12:23:04 - Ike: ConRef=35, XMIT_MSG1_QUICK, name=COMPANY, vpngw=xx.xx.xx.99:4500
24.11.2022 12:23:04 - Ike: ConRef=35, RECV_MSG2_QUICK, name=COMPANY, vpngw=xx.xx.xx.99:4500
24.11.2022 12:23:04 - IkeQuick: Turning on PFS mode(COMPANY) with group 14
24.11.2022 12:23:04 - IkeQuick: ike_phase2:recv_id1:ID_IPV4_ADDR:pid=0,port=0,10.0.27.81
24.11.2022 12:23:04 - IkeQuick: ike_phase2:recv_id2:ID_IPV4_ADDR_SUBNET:pid=0,port=0,0.0.0.0 - 0.0.0.0
24.11.2022 12:23:04 - Ike: ConRef=35, XMIT_MSG3_QUICK, name=COMPANY, vpngw=xx.xx.xx.99:4500
24.11.2022 12:23:04 - IkeQuick: phase2:name(COMPANY) - connected
24.11.2022 12:23:04 - SUCCESS: Ike phase 2 (quick mode) ready
24.11.2022 12:23:04 - IPSec: Conref=35, Created an IPSEC SA with the following characteristics
24.11.2022 12:23:04 - Gateway=xx.xx.xx.99,NatdMode=1,Roamingcon=1
24.11.2022 12:23:04 - srcranges=[10.0.27.81:0-10.0.27.81:65535],
24.11.2022 12:23:04 - dstranges=[0.0.0.0:0-255.255.255.255:65535],
24.11.2022 12:23:04 - IPSec:ConRef=35 connected: Effective ESP LifeDuration in Seconds = 20160,Effective IKE lifetime=20156
24.11.2022 12:31:12 - Pthru: Ip Address Change,index=203,IpAddress=192.168.178.25
24.11.2022 12:31:12 - WLAN adapter <Intel(R) Dual Band Wireless-AC 8260> is connected with SSID <FRITZ!Box 7590>
24.11.2022 12:31:12 - IPSec: Link Status Address Change Received - IpAdr=192.168.178.25,AdapterIndex=203
24.11.2022 12:31:14 - Pthru: Ip Address Change,index=203,IpAddress=192.168.178.25
24.11.2022 12:31:14 - WLAN adapter <Intel(R) Dual Band Wireless-AC 8260> is connected with SSID <FRITZ!Box 7590>
24.11.2022 12:31:14 - IPSec: Link Status Address Change Received - IpAdr=192.168.178.25,AdapterIndex=203
24.11.2022 12:31:14 - osspecific_del_dns: cmdline=netsh interface ipv4 delete dnsservers 10 all validate=no
24.11.2022 12:31:14 - osspecific_add_dns: cmdline=netsh interface ipv4 add dnsservers 10 10.0.1.92 validate=no
24.11.2022 12:31:17 - osspecific_del_dns: cmdline=netsh interface ipv4 delete dnsservers 10 all validate=no
24.11.2022 12:31:17 - osspecific_add_dns: cmdline=netsh interface ipv4 add dnsservers 10 10.0.1.92 validate=no

Kann man auf Basis dieser Protokoll was dazu sagen? Gibt es etwas was ich probieren kann um das Problem weiter einzugrenzen oder zu beheben?

[RaBu78]

Moin,

ich bin ein wenig weiter .

Ich habe die Gültigkeitsdauer von IKE auf 120 Sekunden gesetzt und von ESP auf 60 Sekunden. Damit konnte ich das Verhalten deutlich schneller reproduzieren. Das Verhalten tritt immer dann auf wenn 108 Sekunden (Die Soft-Sec) abgelaufen sind, also beim Ablauf der Gültigkeit von IKE.

Das Problem tritt nur auf mit dem LAC. Wir haben hie noch Shrew Clients mit IKv1 und dort tritt das Problem nicht auf. Habe ich getestet mit den gleichen Werten der Gültigkeitsdauer. Danach habe ich Schrittweise die gleichen Router-Einstellungen von dem Shrew-Client zu dem LAC-Client angeglichen bis diese identisch waren. Keine Besserung.

Danach blieb aus meiner Sicht nur noch die Routing-Tabelle über. Ich habe dann für den LAC-Client eine feste Route eingetragen (weil das mit dem Shrew-Profil auch so ist) und damit funktioniert es. Es scheint so zu sein, dass wenn IKE abläuft und erneut wird (das kann ich in /Status/VPN/IKE) sehen der Routing-Eintrag entfernt wird aber nicht erneut!? Hat da einer eine Idee warum das so ist?

Wenn ich das Profil auf IKv2 umstelle funktioniert es übrigens auch ohne statischen Routing-Tabelleneintrag.

Gruß Rainer