Den allmänna infrastrukturen fungerar som den ska. Jag kan ansluta och få en IP, men jag kan inte få åtkomst till några resurser eller ens pinga RRAS-gatewayn. VPN-servern har en NIC och är bakom vår brandvägg. LAN för servern i vår miljö är 10.3.30.0/24. Jag vill skapa en VPN-DHCP-pool i RRAS, så jag satte upp en som 172.16.70.0/24. När jag ansluter med RRAS DHCP aktiverat, får jag en IP men kan inte komma åt något. Om jag inaktiverar RRAS DHCP och får en 10.3.30.X IP, kan jag komma åt alla interna resurser över olika subnät samma som med vår nuvarande VPN-lösning. Allt jag försöker lista ut är hur jag ska routa trafik från VPN-området (172.16.70.0/24) till de andra nätverken i vår miljö.
Du måste lägga till en statisk rutt på din brandvägg för nätverket 172.16.70.0/24 med en nästa hop till din VPN-server interna IP-adress (förutsatt att din VPN-server är på samma subnet som din brandvägg).
Hör av dig hur det går!
Jag tror att du har det bakvänt. Jag försöker att låta RRAS routa trafik från 172 till 10.3.30, inte säga till 10.3.30 att gå till 172. Jag förstår vad du säger för att trafiken ska vara tvåvägs, men om jag ansluter min testmaskin till RRAS VPN finns det ingen rutt till 10.3.30 i maskinens routing-tabell. Kanske kan skärmdumparna nedan hjälpa
Så en del av mitt problem var varför min testklientsmaskin inte fick en statisk rutt för nätverket 10.3.30 och jag har fått det att fungera. MS-dokumentationen för Always On VPN nämner ingenting om rutter i VPN-XML-profilen. Däremot visar Get-NetRoute -AddressFamily IPv4 eller route print ingen rutt till 10.3.30, men Get-VpnConnection -Name "VPN Namn" | select -exp routes gör det. Jag är inte säker på om det är förväntat, som om VPN-rutter inte visas i routingen för någon anledning. Det känns konstigt
Det känns verkligen inte som att brandväggen är det som saknas här. Min testmaskin kan inte ens pinga den interna RRAS-IP när den är ansluten (172.16.70.1), men VPN-servern kan pinga vilken IP min testmaskin får. Jag känner att det borde finnas ett sätt att säga till VPN-servern “skicka trafik från 172 till 10.3.30.166” (.166 är serverns IP) och sedan sköter brandväggen resten eftersom brandväggen tar emot trafiken från 10.3.30.166
Så till den första frågan, nätverket 172 existerar endast på RRAS-servern. Eftersom jag inte kunde hitta bra dokumentation som bekräftar eller nekar detta, antog jag att skapa nätverket i RRAS var detsamma som att skapa VPN-nätverket på vår brandvägg, vilket innebär att inga ytterligare gränssnitt behövdes. RRAS skulle sedan användas för att routa trafik från 172 till våra andra nätverk.
För tydlighetens skull, körs den nuvarande VPN på vår brandvägg och ingår inte i denna process. Jag ansluter bara min testmaskin till VPN-klienten när jag testar RRAS.
Så jag behöver lägga till en rutt på brandväggen som säger att trafiken från nätverket 172 ska skickas till 10.3.30?
Lyckades du lösa detta? Jag har samma problem. Get-VPNConnection-kommandot visar tydligt rutten, men den visas inte i routingen för enheten.
Det som är irriterande är att när man konfigurerar en ny enhet med autopilot - fungerar det första gången den ansluter. Men efter en omstart under installationsprocessen kan jag se att VPN är ansluten men rutten är borta…
Väldigt frustrerande!
Ingen mängd med att pilla med VPN-DHCP-poolen fungerade, så vi tog ett annat tillvägagångssätt.
Vi flyttade VPN-servern till ett nytt subnet (10.7.70.0/24) och skapade brandväggsregler för att tillåta kommunikation mellan den och LAN:et 10.3.30.0. RRAS tilldelar adresser från nätverket 10.7.70.0.
Vi stötte också på problem med att använda vår on-prem MFA-gateway med Azure efter att ha löst nätverksproblemen. Det fungerar, men accepterar inte alltid den första MFA-godkännandet och uppmanar till ett andra eller tredje tillfälle innan det äntligen fungerar. Jag har försökt titta på det, men min chef gjorde observationen att denna konfiguration skulle träna användare att blint acceptera MFA-pushar eftersom de kommer att bli konditionerade att tro att det bara är VPN:et. Vi planerar inte längre att använda Always On och tittar på andra lösningar för att ersätta vår nuvarande setup.
Det är väl sant, tack för snabbt svar. Vi använder redan ett dedikerat subnet för RRAS-klienter, men VPN-konfigurationen vi pushar via Intune inkluderar routen tillbaka till DC-subnätet, men det vill bara inte fungera ibland.
Ju mer jag läser om detta, desto mer verkar det som en halvhjärtad lösning, åtminstone med inbyggda Windows VPN…
Det är definitivt en Microsoft-lösning, det är säkert.
Jag är egentligen inte säker på vad jag mer kan föreslå, tyvärr. Min största problem var att försöka använda RRAS DHCP-poolen. Routing fungerade bra efter att ha skapat det separata subnetet. Kanske kan du dubbelkolla din XML-konfig? Det är länge sedan jag satte upp detta, så jag minns inte mest av processen utan att kolla MS-dokumentation och min organisation kommer inte att använda det ändå.