Geef op de command prompt (cmd) het command ipconfig /all en zoek naar een VPN interface. Het IP adres dat bij die interface getoond wordt is waar ik naar op zoek ben.

Ik denk dan 145.77.21.199 want daar staat als beschrijving cisco anyconnect en de connection-specific DNS Suffix is mijnwerkgever.nl. 

Nee, dat is hem ook niet, dat is een publiek IP adres.

Een LAN IP adres begint altijd met 10. of 192.168. of 172.16. t/m 172.31.

Dan heb ik geen idee. In die range kan ik niks vinden. Als ik via de wifi inlog op de vpn vind ik wel een 192.168.3.8 (ik heb het subnet naar 192.168.3 veranderd) maar ook een 145.77.21.233, alleen kan ik dan verder niks. Als ik internet open krijg ik vaak de melding DNS_PROBE_FINISHED_NXDOMAIN

In de Cisco Anyconnect secure mobility client geeft hij bij VPN ook het ip adres 145.77.21.233, server is 145.77.11.13

@tomvadek

Met alle zaken die er reeds zijn uitgeprobeerd, inclusief aanpassing van sub-net.
Even een heel andere insteek om te zien of je daar verbetering in zou kunnen krijgen.

N.a.v. eigen ervaring en testen met problemen via één specifieke VPN methode tussen twee routers. Waarbij problemen zich niet voordoen vanuit een VPN Client op een ander apparaat. Net afgelopen weken met tussenpozen daar intensief mee bezig geweest. (Een “marathon” VPN test, waar uiteindelijk “aan het eind” wel 80-100 VPN verbindingen in allerlei combinaties zijn uitgeprobeerd).

In mijn geval bleek het te gaan dat bepaald gebruikte speciale karakters van inlog gebruiksnamen en wachtwoorden niet altijd goed worden opgepakt, en resulteren in een foute VPN-verbinding, terwijl dezelfde gebruikte inloggegevens met speciale karakters dat in andere gevallen wel goed werkt.

Daar zou je specifiek op kunnen testen? Zul je met de systeembeheerder van je bedrijf contact moeten leggen, want die zal voor jou account inlog gegevens daarvoor moeten aanpassen.
In die gevallen dat het mogelijk een vergelijkbare situatie zou kunnen zijn.

Voor mijn situatie betrof het de daadwerkelijk geldende “eind uitkomst” na zo'n marathon test. Waarbij men goed in de gaten moet houden dat storingen ook op heel ander gebied kunnen liggen, die men ook moet doorzien en “eruit” filteren als eigenlijk niet een echte “systeemfout”.

Het is een heel uitzoek traject geworden, waarbij ook die andere aspecten van verbroken of niet goedwerkende VPN-verbindingen in zijn algemeenheid uit de doeken worden gedaan.
Is ook allemaal beschreven. De tips en aanbevelingen daarbij kun je ook in ogenschouw nemen.

Meer daarover te vinden, op het forum van Synology, inleiding / aanleiding vanaf < HIER >
Tips en aanbevelingen vanaf de 2e reactie bij het onderwerp, oplossing vanaf 3e reactie.

Helaas weten we nog altijd niet wat het subnet van het netwerk van het bedrijf van @tomvadek terwijl de oorzaak toch daarin gezocht lijkt te moeten worden. 

Het is immers via het gastnetwerk van de V10 (subnet 172.16.0.0/12) mogelijk om met die VPN verbinding op Internet te komen terwijl dat via het gewone netwerk van de V10 niet mogelijk lijkt.

Van de week heb ik op een kantoor van ons gewerkt en volgens mij werkt het daar hetzelfde als dat ik thuis werk, alleen op werk log je automatisch in als je verbinding maakt met de wifi daar waar ik thuis eerst op connect moet klikken bij anyconnect en dan mijn inloggegevens moet invoeren.
Als ik op werk ipconfig /all doe dan zie ik wel een ip adres met 10. namelijk 10.91.140.8. Het is mij alleen niet duidelijk hoe ik kan zien wat het ip adres binnen het VPN netwerk is. 

@Babylonia als ik het goed begrijp zou het dan aan speciale tekens in mijn inlog of wachtwoord kunnen liggen? Inlog is redelijk standaard volgens mij, naam.achternaam@bedrijf.nl en in mijn wachtwoord heb ik nu geen speciale karakters zitten, eisen zijn minimaal 12 karakters, één hoofdletter, één kleine letter en één cijfer. 

Nu is dat niet helemaal correct, een bedrijf (en zeker een overheidsinstelling) kan ook een netblock eigenaar zijn welke ze (ten dele) gebruiken voor de VPN oplossing (juist om ip conflicten in een thuis situatie te voorkomen) 

@tomvadek  mocht het nog kunnen is het privacy technisch beter om het 145 adres even te verwijderen uit je posts. 

De Cisco Anyconnect oplossing is er een die vele vormen kan hebben waardoor het voor ons lastig is om echt te troubleshooten. en zoals eerder gezegt is dit echt iets waar je bedrijf naar moet kijken.

Gewoon al omdat de beleidsregels van de Cisco Anyconnect bij ons niet bekend zijn,  en hierin kunnen we allemaal gokken en aannames doen en dat zijn allemaal valide aannames… maar mogelijk niet van toepassing op jou configuratie. bijvoorbeeld: blokkeert je bedrijf mogelijk zaken in de 192.168.x.x range. En wat voor VPN configratie is het eigenlijk (IKE of IKEv2), Is packet fragmentation toegestaan of niet, en zo nee hoe groot zijn de packets dan. 

Het beste zou zijn om de netwerk pakketten te gaan tracen 

En ja het is gek dat het op de oude gast configuratie wel werkte en op de nieuwe niet. Nu gebruik ik het niet maar mogelijk dat het gastnetwerk voorheen anders (lees minder veilig) behandeld werd door de Experiabox dan het reguliere netwerk en dat kpn dat eindelijk gelijk heeft getrokken (en jou daarmee in de problemen brengt)

Geen vreemde karakters, maar er is misschien mogelijk wel verband te zoeken in de combinatie van een “e-mail” adres als login naam??  Ik geef toe, ver gezocht, maar heb wel eens meer vreemde zaken voorbij zien komen.

Een e-mail adres wordt vaker als inlognaam gebruikt. Afhankelijk van allerlei achterliggend “geautomatiseerde” functies in “herkennen” door programma's van een “e-mail adres”, zou er mogelijk een andere functie kunnen worden gekoppeld dan de bedoeling??
Of achterliggend een opgeslagen / vastgelegd IP-adres of sub-net?
(Intern bij je bedrijf heb je er geen last van).

Heb het bijv. wel eens gezien bij een NAS, waar een "Apple” gebruiker die  t/m  in de naamgeving van mapjes zette, bij een storing in de connectie bij toeval dat schuine / streepje werd opgevat als "deelstreepje" van mapjes van een directory, waardoor die directory indeling anders werd opgepakt.

Je zou eens kunnen proberen een andere laptop (van een collega) bij je thuis ook een VPN verbinding met je bedrijf op te zetten, om te zien of die tot dezelfde fouten komt?
En indien geen fouten, eens met je eigen login gegevens proberen met diens laptop in te loggen.