Hej allihop,
Jag hade en OpenVPN-klient inställd för en av mina kollegor. VPN-klienten upprättar koppling precis som den ska när den är direktansluten till en edge-router. Men när den är bakom vår checkpoint-brandvägg kopplas den ner nästan omedelbart. Jag tillät alla nödvändiga portar för den specifika maskinen och den fjärrstyrda OpenVPN-servern på Checkpoint R77.30, men problemet kvarstår. Jag
Any hjälp skulle vara mycket uppskattad. Tack.
Filtrerar du bara destinationen?
Jag antar att OpenVPN-servern är på internet och klienten har en privat adress, så det är troligt att någon form av NAT sker eftersom SYN-paketet når OpenVPN-servern. Troligen ett standardfuffen bakom gatewayadressen.
Gör detta på brandväggen.
fw ctl zdebug + drop | grep 1.2.3.4
Där 1.2.3.4 är IP-adressen till OpenVPN-servern. Det borde visa om brandväggen slänger trafiken av någon annanstans än en vanlig policy.
Jag hade ett liknande problem med Juniper-enheter som var placerade bakom Checkpoint FW (R80.10). IPSec-tunneln som avslutades på denna SRX var mycket ostabil. Efter många försök tillät jag all trafik till käll- och destinations-IP och inaktiverade helt NAT-reglerna, men ändå var tunneln fortfarande ostabil.
Till slut flyttade jag Checkpoint bakom SRX, och sedan försvann alla mina problem. Jag kan inte förklara detta på något tekniskt sätt, men det verkar som om även för tillåten trafik är inspektionen av checkpoint skadlig för krypterad trafik.
Djinjja, trafiken NATas inte. Skulle NAT av trafiken hjälpa till att upprätta anslutningen? Vi filtrerar inte trafiken med applikationsnivåregler. Kollade loggarna på brandväggen med käll- och destinations-IP som filter; det finns ingen indikation på att VPN-trafiken passerar brandväggen. Men varje gång jag återansluter VPN-klienten ökar rule hit counts. Loggarna på VPN-klienten visar att klienten fastnar på väntet efter att TCP-anslutningen redan är upprättad. Wireshark-fångst visar att servern skickar ett RST-paket efter SYN-ACK, vilket gör att det ser ut som att servern bryter kopplingen när klienten inte svarar. Tack för hjälpen.
Försök att filtrera endast på destinationen.
Jag antar att OpenVPN-servern är på internet och klienten har en privat adress, så det är troligt att någon form av NAT sker eftersom SYN når OpenVPN-servern. Troligen en standard som gömmer sig bakom gatewayadressen.
Gör detta på brandväggen.
fw ctl zdebug + drop | grep 1.2.3.4
Där 1.2.3.4 är IP-adressen till OpenVPN-servern. Det bör visa om brandväggen blockerar trafiken av någon annan anledning än en vanlig policy.
Hoppas detta hjälper!
Du är en livräddare! Debuggen visade att paketet slängdes av en applikationskontrollpolicy. Det visade sig att det var URL-filtrering på plats – som jag inte visste om – som blockerade VPN-trafiken. Skapade en ‘tillåt’ regel ovanpå och VPN anslöt prima. Tack, Djinjja.