IPSec

Dawno, dawno temu pisałem, że wiesza mi się karta sieciowa. Ówczesne zeznania muszę albo zmienić (albo coś się zmieniło). Wcale nie musi być włączony pf, musi być za to IPSec. Niestety, nawet w wersji 4.2 (jeszcze nie wydanej) problem występuje... Na chwilę obecną wydaje mi się, że jestem go w stanie wywołać w 100% powtarzalnie.

Po prawie 5 latach mieszkania w jednym mieszkaniu i posiadania w niej sieci, nastał czas zmian. Zmiana mieszkania, zmiana organizacji sieci. Do tej pory dostęp do internetu zapewniał mi komputer pracujący pod kontrolą Gentoo, a drugi, pracujący pod kontrolą OpenBSD pełnił rolę Access Point dla moich laptopów. Nowe mieszkanie ma jednak mniej zakamarków, w których mógłbym pochować kable, więc po pierwsze postanowiłem większość komputerów podpiąć bezprzewodowo, a po drugie stwierdziłem, że może dwa, ciągle włączone komputery, to jednak przesada jest, w związku z czym główną rolę przejmuje OpenBSD. Ale by nie było za łatwo (bo ja zawsze mam pokręcone wymagania)...

...jakiś czas zrobiłem sobie IPSec w trybie tunelowym między moim laptopem i AP. Wszystko w tym celu, by zabezpieczyć się przed ewentualnym podsłuchem ruchu WiFi. Niestety, jest jeden, mały problem: You can configure Windows XP as the endpoint of a tunnel mode IPSec connection. However, we do not recommend this. If you use the IPSec connection in tunnel mode, the Windows XP SP2 Windows Firewall feature does not filter any packets that come out of the IPSec tunnel. However, packets that come from other directions are filtered by the Windows Firewall feature.

Z uwagi na problemy, które występowały w poprzedniej konfiguracji IPSec, nieco zmieniłem konfigurację po stronie OpenBSD. Obecnie wykorzystuję isakmpd nie tylko do negocjacji kluczy, ale również do zestawiania tuneli.

Ponieważ opisywane przeze mnie problemy z IPSec stawały się dla mnie coraz bardziej uciążliwe, postanowiłem je zacząć dokładniej diagnozować. W tym celu uruchomiłem tcpdump na ral0 i fxp0 oraz uruchomiłem isakmpd z opcją -L. W efekcie zebrałem trochę materiału, nawet ciekawego dość, przyznać muszę. Wygląda na to, że Windows... cieknie...

Od pewnego czasu irytuje mnie pewna przypadłość IPSec, który wykorzystuje do zabezpieczenia komunikacji WiFi. Wszystko ładnie działa, ale po suspendzie komputera coś czasami nie działa tak jak powinno. I w końcu szukam tego czegoś...

Wygląda na to, że powodem rozłączączania się WiFi po suspendzie był... IPSec. Stacja wysyłała trzy razy zapytanie DHCP do serwera, serwer kulturalnie odpowiadał, ale fakt wysłania tego samego zapytania sugeruje, że stacja go nie odebrała. A dlaczego? Bo być może oczekiwała na pakiet zabezpieczony przez IPSec? Jak będę miał więcej czasu (w co jednak wątpię w najbliższej przyszłości), to może przedstawię więcej informacji na ten temat. W każdym razie dodanie reguły pozwalającej w jawny sposób na ruch DHCP bez zabezpieczeń IPSec wydaje się, że pomogło.

Chyba powoli doszedłem do tego, dlaczego czasami po suspendzie IPSec nie chce mi się zestawić. No, właściwie to on mi się zestawia... Zachodzą następujące zdarzenia:

• Komputer "wstaje" z suspendu
• Karta nawiązuje połączenie
• IPsec jest negocjowany
• Karta zrywa połączenie i nawiązuje je ponownie

Po ponownym nawiązaniu połączenia IPSec już nie działa, przy czym to jest raczej tak, że trzymane są stare SA, ale pakiety nie są prawidłowo w nich widziane. Ale temu tematowi muszę przyglądnąć się dokładniej. Na razie próbuję różnych sztuczek, by nie było owego zrywania połączenia po suspendzie...

Tak, z IPSec, teraz już wiem na 100%, że problemy z łączem występują tylko wtedy, gdy ruch między laptopem a AP jest szyfrowany przy pomocy IPSec (efekt uboczny - douczyłem się nieco konfiguracji ipsec pod OpenBSD). Ale trudno stwierdzić gdzie właściwie problem leży...

Problem z ICMP już rozwiązałem, okazał się banalny. Wystarczyło zainstalować jedną poprawkę, a problem był opisany w artykule ICMP packets are dropped even though you have configured the Windows firewall feature to allow ICMP packets on your Windows XP Professional Service Pack 2-based computer.