Jag är ny på Sonicwall och jag har problem med SSH. Jag försöker SSH:a från en laptop till en server när jag är på IPSec VPN och får följande fel på SSH-klienten:
kex_exchange_identification: read: Connection reset
Jag har aktiverat SSH-hantering på VPN-inställningarna och trodde att detta kunde vara problemet. Jag övervakade paketen och såg en syn ack-utbyte, men sedan slängdes paketen med detta fel.
Applikationshuvud
SSH
Värde:[1]
Slängd, Drop-kod: 737 (Packet dropped - cache add cleanup drop the pkt), Modul-id: 25 (nätverk), (Ref.Id: _2297_dbdifBeeDmfbovq) 2:2)
När jag är direkt på nätverket har jag inga problem med SSH mellan dessa två maskiner. Jag har satt upp en brandväggsregel för att tillåta all trafik mellan VPN och LAN i båda riktningarna. Det verkade inte hjälpa. Jag är helt uttömd på idéer. Några tankar?
Om du använder samma användar-ID är återställningen för att du kan bara vara inloggad som den användaren en gång. Du skulle behöva tillåta flera samtidiga inloggningar för att förhindra det.
Kan brandväggen göra SSH DPI? Och därigenom presentera Sonicwall-certifikatet/nyckeln?
Är bara nyfiken. Kan du se att porten är öppen när du använder något som nmap på VPN till enheten i fråga?
Har du SSH IP-subnetztsregler på SSH-servern? Kontrollera SSH-konfigurationsfilen och brandväggsregeln på SSH-servern.
Tankar högt. Cache add cleanup är inte en åtgärd, det är ett svar på en redan gjord åtgärd. Anslutningen var redan stängd, så Sonicwall tog bort sina register. En idé är att söka efter målserverns adress i loggarna och se om något dyker upp. En annan tanke är att göra en paketfångst och se om Sonicwall ens gör det. Du sa inte vilken OS servern kör, har SSH-serverprocessen tillåtelsefilterregler? Vilket subnät placerade du GVPN-klienterna på? Personligen skulle jag börja med att göra en paketfångst.