Administrace komentářů

L2TP over IPSEC funguje přes IPSEC. Forwarde čehokoli jiného než portů UDP500 a 4500 je zbytečné, protože nejdříve se naváže IPSEC tunel a přes něj se pak tuneluje veškerý L2TP provoz, tj. i provoz na zmíněném portu 1701 apod. (L2TP je nešifrované, proto se tuneluje přes IPSEC, proto ani logicky nemůžeš dělat forwarde 1701, to by ti ten IPSEC byl pak k ničemu)
Osobně jsem L2TP za NATem řešil nedávno. Kolegové dostali úkol rozjet L2TP pomocí pfSense. Když to měli 14 dní na stole a nehli s tím, tak jsem se na to podíval. Kromě toho, že to měli špatně nastaveno a já dělal také jednu chybu, viz :
pfSense 2.3.2 : L2TP - no matching CHILD_SA config found
Jsem přišel i na to, že kernel z FreeBSD (na něm je pfSense založeno) zahazuje packety, u nichž nesedí checksumm. To dělá problémy právě u L2TP v případě, že je za natem. Řešilo se patchováním FreeBSD kernelu : Howto set up a L2TP/IPsec VPN Dial-In Server (Part I to III)
Dále, aby Windows také akceptovaly chybný checkum, tak je třeba jim hodit do registrů tento klíč (myslím, že Vista a výše):

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\PolicyAgent
AssumeUDPEncapsulationContextOnSendRule dword:2

pfSense používá nejnovější strongswan 5.5.0 a pro L2TP používá mpd5 (linux má xl2tpd).
Každopádně, co tím chci říci, pokud chceš provozovat jen IPSEC, tak ok, NAT není problém na obou stranách. Pokud chceš provozovat L2TP over IPSEC, tak měj na serveru nastavenou veřejnou IP, v opačném případě budeš řešit problémy s NATem.
Jinak u toho pfSense jsem se dostal k tomu, že IPSEC fáze 2 proběhla, navázala se přes tunel komunikace na portu 1701 a pak šlo spojení dolu, fáze s L2TP se nedokončila a logy mlčely.
Linux se asi v tomto případě bude chovat přívětivěji, což je evidentní i z toho, že ten odkazovaný návod je také s rpi za NATem, ale už jen to, že týpek radí forwardovat port 1701 značí to, že tomu asi do hloubky moc nerozumí.
Další věc, na kterou si dávat bacha. Strongswan umí více L2TP klientl za stejným NATem až od určité verze, tak bacha na to, jakou verzi implementace používáš + na to, jestli budeš mít více klientů za stejným NATem.
Pokud máš ovšem problém s tím, že při pokusu o připojení win stanice z internetu nemáš na rpi v logu ani hlášku, tak to bude asi problém opravdu špatného nastavení forwarde.
Zdar Max
PS: neměl jsem moc time na zkoušení, osobně by mně zajímalo, jak se bude chovat L2TP over IPSEC server za NATem u linuxu, jinak u nás se řeší L2TP pro cca 300 uživatelů, takže provoz serveru za NATem jsem zavrhl (člověk nikdy neví, jaká implementace je na straně klienta a po uživatelích nemůžeš chtít, aby si něco importovali do registrů apod.)