Remote access VPN to jeden z tych tematów, gdzie różnica między rozwiązaniem open-source a komercyjnym jest najbardziej odczuwalna. Nie chodzi tylko o licencje. Chodzi o to, co dzieje się o 2 w nocy, kiedy 300 użytkowników nie może się połączyć z biurem. 

OPNsense jako platforma VPN 

OPNsense to oparty na systemie operacyjnym BSD firewall z bogatym ekosystemem pluginów. Wywodzi się z pfSense, ale od lat idzie własną drogą i dziś jest dojrzałym wyborem dla wielu administratorów, szczególnie tam, gdzie liczy się przejrzysty interfejs i regularne aktualizacje bezpieczeństwa. Natywnie obsługuje OpenVPN (SSL/TLS, port 443 TCP lub UDP), WireGuard (natywnie od wersji 22.x, bez potrzeby zewnętrznych pluginów), IPSec z IKEv2 oraz L2TP/IPSec, który należy traktować jako legacy i nie polecam go w nowych wdrożeniach. 

Dla użytkowników remote access wybór w praktyce sprowadza się do OpenVPN lub IKEv2/IPSec. WireGuard jest kuszący swoją wydajnością, ale brakuje mu dojrzałości w zakresie zarządzania certyfikatami i integracji z katalogami użytkowników w typowych środowiskach korporacyjnych. 

OpenVPN 

Instalacja i konfiguracja oparte są na GUI, które przy pierwszym kontakcie wydaje się intuicyjne. Do momentu, gdy chcemy wdrożyć coś nietrywialnego. Przykład z życia: chcemy, żeby użytkownicy z grupy AD „Contractors” mieli dostęp tylko do podsieci 10.50.0.0/24, a pracownicy mieli pełny routing. W Cisco ASA robimy to przez Dynamic Access Policies. W OPNsense musimy kombinować z client-specific overrides w OpenVPN i ręcznie przypisywać reguły firewall do interfejsu VPN. 

Eksport konfiguracji klienta obsługuje plugin openvpn-client-export. Generuje on gotowe pliki .ovpn z certyfikatami. Brzmi świetnie i często działa. Ale klient Windows ma tendencję do problemów z MTU i split DNS w sieciach korporacyjnych, gdzie firewall po drodze fragmentuje pakiety. 

Integracja z LDAP/AD działa natywnie. Możemy skonfigurować RADIUS z obsługą MFA przez TOTP, dzięki czemu wymusimy dwuskładnikowe uwierzytelnianie użytkowników, którzy pracują zdalnie. Brakuje jednak natywnego wsparcia dla SAML i nowoczesnych produktów takich jak Okta czy Azure AD. Rozwiązanie? RADIUS proxy z NPS na Windows Server albo FreeRADIUS z odpowiednimi modułami. Pamiętajmy jednak, że dodatkowa warstwa to zawsze potencjalnie dodatkowy punkt awarii. 

IKEv2/IPSec 

IKEv2 z EAP-MSCHAPv2 lub Machine Certificates to natywny protokół dla Windows, macOS i iOS. Nie potrzebujemy dodatkowego klienta. Użytkownicy łączą się przez mechanizmy wbudowane w system operacyjny. Konfiguracja IPSec na OPNsense potrafi jednak doprowadzić do szału, co wynika z samej natury protokołów IKEv2 i IPSec i mnogości parametrów, które musimy skonfigurować. Phase 1, Phase 2, proposals, DH groups, PFS, rekey timers. Każdy błąd daje ten sam mało mówiący komunikat: „No proposal chosen.” Debugowanie sprowadza się do czytania logów ze strongSwan przez CLI i szukania rozbieżności w algorytmach między klientem a serwerem. Komunikaty błędu mogą w tym przypadku być bardzo mylące, a logów produkowanych jest bardzo dużo. 

Typowy scenariusz: Windows 11 proponuje AES-256-GCM z SHA-384 i ECP-384. Mamy skonfigurowane AES-256 z SHA-256 i DH group 14. Połączenie nie wstaje. Musimy albo dostosować klienta przez PowerShell, albo dodać odpowiedni proposal po stronie serwera. OPNsense używa strongSwan jako backend, co daje nam więcej możliwości diagnostycznych niż starsze implementacje oparte o racoon. 

OPNsense jako klient VPN: niedoceniany scenariusz 

Większość artykułów o OPNsense skupia się na firewallu w roli serwera. Tymczasem OPNsense świetnie sprawdza się też jako klient VPN, co otwiera kilka interesujących scenariuszy architektonicznych. 

Zamiast instalować klienta OpenVPN na każdej stacji roboczej w oddziale, konfigurujemy OPNsense jako klienta OpenVPN. Cały ruch z sieci oddziałowej jest automatycznie tunelowany do centrali bez żadnej konfiguracji po stronie użytkownika. To klasyczny remote-access zamieniony w site-to-site, ale realizowany przez klienta OpenVPN, a nie przez natywny IPSec. Praktyczna zaleta – kiedy centrala wymaga, żeby ruch z oddziału był poddawany inspekcji przez korporacyjny IPS, a my nie mamy możliwości zestawienia IPSec site-to-site, OpenVPN client na OPNsense rozwiązuje problem elegancko. 

OPNsense może zestawiać połączenia IKEv2 jako inicjator do zewnętrznych koncentratorów. Używamy tego, gdy oddział musi połączyć się z infrastrukturą zarządzaną przez inną organizację, np. z Azure VPN Gateway lub AWS VPN. W tym scenariuszu często napotykamy problem z NAT-T. Jeśli OPNsense stoi za NATem naszego operatora internetowego (CG-NAT lub standardowy PAT), IKEv2 musi używać enkapsulacji UDP 4500. Większość nowoczesnych implementacji obsługuje NAT-T automatycznie, ale zdarzają się sytuacje, gdzie trzeba to wymusić ręcznie w konfiguracji strongSwan. 

WireGuard w roli klienta to scenariusz, który widzimy coraz częściej, na przykład, gdy firma korzysta z Cloudflare WARP for Teams lub własnego serwera WireGuard w chmurze. OPNsense w oddziale łączy się jako peer i cały ruch wychodzący jest tunelowany przez ten serwer. WireGuard jako klient ma jedną cechę, która bywa zarówno zaletą, jak i problemem: jest to mechanizm bezstanowy w sensie sesji. Nie ma renegocjacji jak w OpenVPN. Jeśli serwer zmieni IP, klient musi być zrestartowany lub skonfigurowany z mechanizmem keepalive i dynamicznym DNS po stronie serwera. 

Cisco ASA/Firepower i Fortinet FortiGate: co mają, czego nie ma OPNsense 

Nie ma sensu udawać, że nie ma różnic między darmowym rozwiązaniem open-source a komercyjnymi produktami. Różnice są i to istotne. 

Cisco Secure Client (dawniej Anyconnect) to jeden klient obsługujący SSL VPN i IKEv2, rozpoznający sieci korporacyjne i automatycznie przełączający profile. Trusted Network Detection działa niezawodnie, a uzupełnić możemy go o Always-On VPN. Mechanizm Posture Assessment sprawdza, czy klient ma aktualny antywirus przed przyznaniem dostępu. Grupowe polityki z DAP, split tunneling z DNS routing rules. Wszystko w jednym produkcie z dokumentacją i dostępem do wsparcia Cisco TAC. Barierą dla wielu może być jednak cena. Licencje Anyconnect to znaczący koszt, do tego licencje na samą ASA lub Firepower. 

FortiGate z FortiClientem prezentuje podobny poziom dojrzałości. FortiClient obsługuje IPSec i SSL VPN (ten jest w nowych wersjach usuwany), integruje się z FortiEMS aby zapewnić szeroko pojęte endpoint compliance. Zarządzanie przez FortiManager w dużych środowiskach jest sensowne, choć FortiManager ma swoje wady. Fortinet ma lepszy stosunek cena/możliwości niż Cisco. Jednakże FortiClient bywa kapryśny na macOS po każdej aktualizacji systemu, nie mówiąc o praktycznym braku rozwoju klienta na urządzenia mobilne – wymusza to rezygnację z wysokiego poziomu ochrony na rzecz kompatybilności. 

Wybierając koncentrator VPN, musimy szczególnie przyjrzeć się kilku aspektom. Pierwszym z nich jest wydajność. OPNsense na dedykowanym sprzęcie bez problemu uniesie kilkadziesiąt równoległych sesji VPN. Ile, zależy od mocy urządzenia. Niestety w dokumentacji nie znajdziemy dokładnych i wiarygodnych danych pozwalających na odpowiednie wymiarowanie rozwiązania, w szczególności w połączeniu z innymi funkcjami – uruchomiony IPS Suricata też wymaga mocy obliczeniowej i pamięci. To wszystko powoduje, że dość szybko zaczynamy czuć ograniczenia i musimy myśleć o rozwiązaniach realizujących więcej funkcji w sposób sprzętowy lub o load balancingu. ASA 5555-X z odpowiednimi licencjami obsłuży tysiące sesji bez mrugnięcia. 

Kolejnym aspektem jest wysoka dostępność rozwiązania. OPNsense wykorzystuje protokół CARP do realizacji failover. Sam mechanizm działa, ale synchronizacja stanu sesji VPN między nodami to temat na osobny artykuł pełen bólu. W Cisco i Fortinet HA VPN clustering jest przetestowany i udokumentowany na setkach wdrożeń. 

W OPNsense mamy logi, które czytamy oczami lub przepychamy przez syslog do SIEM. W FortiGate jest FortiAnalyzer, w Cisco integracja ze Stealthwatch. To robi różnicę w sieciach korporacyjnych, gdzie korelacja zdarzeń między endpointem a tunelem VPN jest krytyczna. 

Na koniec warto też pomyśleć o kwestii wsparcia producenta. Kiedy coś się psuje o 2 w nocy, otwieramy zgłoszenie do Cisco TAC lub Fortinet support. Z OPNsense mamy Business Edition przez Deciso. To nie jest złe, ale to nie jest TAC z gwarantowanym SLA i inżynierami z dostępem do kodu urządzenia. 

Rzeczywiste problemy przy wdrożeniu 

Przez lata konfigurowania OPNsense kilka problemów wraca regularnie. Znam je z doświadczenia, poczytać też możemy o nich na różnego rodzaju forach dyskusyjnych, Poniżej kilka z nich: 

• Split DNS i routing. Chcemy, żeby klienci VPN rozwiązywali nazwy wewnętrzne przez nasz DNS, a ruch do Internetu szedł lokalnie. W OpenVPN push-options dhcp-option DNS i route działają, ale Windows bywa oporny przy stosowaniu DNS overrides. Trzeba testować na różnych wersjach klientów i systemów operacyjnych, bo zachowanie różni się między Windows 10 a Windows 11. To powoduje dodatkowy nadmiar pracy dla administratorów. 

• MTU i fragmentacja. OpenVPN over UDP z domyślnym MTU (ustawionym na 1500 bajtów) i enkapsulacją TLS generuje pakiety za duże dla niektórych łączy. Objaw klasyczny: małe pliki przechodzą, duże nie. Rozwiązaniem jest ustawienie parametrów tun-mtu 1400 i mssfix 1360 w konfiguracji. Ale każde środowisko jest inne i wartości trzeba dobrać empirycznie. 

• Certyfikaty. Wewnętrzne CA w OPNsense jest wystarczające do zarządzania certyfikatami VPN, ale jeśli chcemy integracji z korporacyjnym PKI opartym na Microsoft CA, musimy ręcznie importować cały łańcuch certyfikatów CA i pilnować odnawiania certyfikatów. Nie ma tu automatyzacji porównywalnej z zintegrowanym mechanizmem SCEP w Cisco. 

• Aktualizacje. OPNsense regularnie wydaje aktualizacje, co jest zaletą z punktu widzenia bezpieczeństwa. Po każdej warto sprawdzić, czy VPN nadal działa poprawnie. Szczególnie dotyczy to IPSec, gdzie zmiana wersji strongSwan potrafi zmienić domyślny zestaw parametrów wysyłanych w ramach proposals i zepsuć działające połączenia bez żadnego ostrzeżenia. 

• Logowanie i troubleshooting. GUI pokazuje tylko część logów. Przy poważnych problemach i tak lądujemy w SSH i grepujemy przez /var/log/. Znajomość CLI jest obowiązkowa. Nie ma tu nic złego, ale warto o tym wiedzieć przed wdrożeniem w środowisku, gdzie dostęp do CLI jest ograniczony lub gdzie oczekuje się pełnego GUI w procesie troubleshootingu. 

Kiedy OPNsense wystarczy, kiedy nie 

To już subiektywna opinia, bo każde środowisko jest inne. OPNsense sprawdza się w firmach z niewielką liczbą użytkowników, w środowiskach, gdzie mamy kompetentnego admina sieciowego, w projektach, gdzie budżet na licencje jest ograniczony oraz wszędzie tam, gdzie VPN nie jest krytyczną zależnością biznesową wymagającą gwarantowanego SLA.  

Po Cisco lub Fortinet sięgamy, gdy mamy wielu równoległych użytkowników VPN, potrzebujemy zaawansowanych funkcjonalności takich jak endpoint posture assessment, gdy compliance wymaga certyfikowanego sprzętu i oprogramowania lub gdy potrzebujemy wsparcia 24/7 z gwarantowanym czasem reakcji.