Advies mbt VPN server opzetten.

[Ernie]

nav mijn eerdere vragen en antwoorden erop in volgende threads, nl VPN op Android phone via 4G: doenbaar? en OpenVPN configuratie: LAN achter server bereiken én oa het feit dat het met OpenVPN maar niet wil lukken, ben ik verder op zoek gegaan.

Zoals eerder al geschreven heb ik een tijd geleden wel gebruik van PPTP VPN gemaakt maar wijselijk besloten dat toch niet meer te doen.
Ik heb geen router die VPN ondersteunt en wil daar ook niet in investeren maar kan wel een container met linux (Debian) optuigen voor dit doel.
Bij het zoeken kwam ik deze tut (https://site.elastichosts.com/blog/linu ... vpn-server) tegen, waar dus openswan wordt gebruikt
Gebruikt iemand van jullie L2TP/IPsec VPN of zijn er andere/betere alternatieven?

[CCatalyst]

IPSec met IKEv2 voor het beheer van de key exchange is de meest moderne en performante oplossing vandaag. Het werkt ook vlot met mobiele toestellen: de CPU wordt niet zwaar belast (spaart batterij) en de VPN sessie wordt seamless behouden bij roaming van cell naar cell of cell naar Wi-Fi (en omgekeerd) of Wi-Fi naar Wi-Fi. Het heeft native ondersteuning in moderne besturingssystemen, in oudere veel minder. De data wordt 1 keer geencapsuleerd door IPSec (behoudens specifieke configuraties als GRE/IPSec). Het is complexer om te configureren.

L2TP dateert van de jaren 90. Het is even veilig daar het dezelfde security algoritmes toepast, het wordt ondersteund in moderne en oudere systemen, maar is gevoelig trager dan IPSec met IKEv2 omdat de data twee keer geencapsuleerd wordt, een keer door PPP en dan nog eens door IPSec. Dat vereist niet alleen meer CPU rekenkracht, het betekent ook dat er minder data in de pakketten kan en er dus meer pakketten gestuurd moeten worden voor dezelfde data. Noot: dubbele encapsulering verhoogt de veiligheid niet (het vermindert het ook niet). L2TP gebruikt ook IKE voor het IPSec onderdeel, maar wel de oudere IKEv1 variant die bijvoorbeeld seamless roaming niet ondersteunt.

Als mobiele toestellen er gebruik van maken, en/of snelheid van belang is en/of het voor veel data is zou ik vandaag richting IPSec met IKEv2 gaan. Zoniet is L2TP/IPSec nog steeds een goed alternatief, zeker als dat makkelijker is om te configureren.

[dupondje]

Kijk eens naar WireGuard. Is vrij nieuw, maar focus op eenvoud en snelheid!
Er is een app voor Android en iPhone

[GuntherDW]

Alhoewel een tunnel opzetten met IPSec icm strongswan (ik raad wel aan van de nieuwe swanctl config layout e.d. te gebruiken) niet het meest gebruikersvriendelijk is,
is het wel aan te raden als je ook gebruik maakt van een "always on" VPN op android.
IKEv2 is inderdaad de modernste, maar dat heeft wel als nadeel dat Windows 10 niet zomaar een tunnel kan maken ermee. Laat staan als je enkel van ipsec tunnel ID en PSK gebruik wil maken.
Ik heb de indruk dat ze enkel de variant met client certs willen ondersteunen, alsook de oude L2TP variant?

Wireguard zou ik enkel nemen als je VPN niet "always on" op je phone moet zitten.
Zoals ik in de vorige topics heb gemeld is dit slechter voor je batterij en CPU usage.

Als je een moderne CPU hebt kan je ook gebruik maken van de hardware acceleration om zo minder hard je CPU te hoeven belasten en tegelijk hogere throughput te krijgen.
Een router welke dit kan doen hoeft niet duur te zijn trouwens. Bijna elke mikrotik router heeft IPSec hardware offloading, al is dit ook afhankelijk van je firewall rules natuurlijk.
https://wiki.mikrotik.com/wiki/Manual:I ... celeration

Als je niet al te veel van netwerken afkent (en geen zin hebt om het te leren) is het misschien niet echt aangeraden van voor Mikrotik te gaan echter.
Ik heb hier thuis een RB750Gr3 ( https://mikrotik.com/product/RB750Gr3 ) waarop ook een IKEv2 tunnel configuratie opstaat. Ik maak dan verbinding op m'n Galaxy S6 over die IKEv2 tunnel en merk amper iets qua battery usage, zelfs al staat die >20u aan.

[CCatalyst]

Ik heb de indruk dat ze enkel de variant met client certs willen ondersteunen, alsook de oude L2TP variant?

Geen idee, heb geen Windows, maar PSK is eigenlijk nooit een goede keuze tenzij om eens te testen of indien je andere vormen van filtering heb. Zelf gebruik ik uitsluitend X.509.

Dat gezegd zijnde zou het voor de rest wel vlot moeten werken op de laatste Windows besturingssystemen. Microsoft heeft IKEv2 mee ontworpen.

[GuntherDW]

Als het maar voor een kleine zelf opgezette setup is met hooguit 1 of 2 clients is het voldoende IMO.
Met OpenVPN zijn self signed certs niet zo een probleem. Met IPSec is het wat meh.

Nu heb ik zelf ook geen windows maar het was wat rammelen om het in orde te krijgen op de laptop van mn ouders als ze op reis gaan.

Ik moet eens een cert in orde krijgen inderdaad maar op een MT is dat ook nogal meh.

Maargoed. Dit gaat niet over mijn VPN maar van de OP

[Ernie]

Dus IPSec met IKEv2 is the way to go.

Is strongswan dan de enige/beste optie voor op een Debian server?
Volgens wat ik lees wordt het in moderne OS'sen ondersteund, maar niet op W10?
Ook zie ik op de strongswan site dat er een app is voor Android, werkt het daar dan ook niet out of the box?

@GuntherDW: hoe doe jij dat op je S6?

[GuntherDW]

Gezien het "enkel" een tunnel ID en PSK is, kan ik gewoon die dingen invullen bij "add new VPN" zonder extra tooltjes of workarounds eigenlijk.
Het kan zijn dat Samsung (of de oude Android 7.0 welke erop draait) er een ander likje verf op heeft gedaan maar als ik "add VPN" doe kan ik bij type gewoon "IPSec IKEv2 PSK" kiezen.

Dan hoef ik maar de settings in te vullen, connecten en klaar.

Screenshot_20191214-233311.jpg

Het meeste configwerk zit aan de kant van je strongswan, of router, of welk device dan ook welke je als server laat dienen.
Als je met certs gaat werken gaat het iets meer moeite zijn (lees: p12 of ander formaat op de phone krijgen), maar overall is het hetzelfde eigenlijk.

Het grootste probleem voor "always-on" gaat hem liggen in het feit dat hij dan geen hostname gaat accepteren in het address field, maar enkel een IP accepteert. Als je een dynamisch IP hebt gaat dat wat problemen veroorzaken dus.

[CCatalyst]

Kijk eens naar WireGuard. Is vrij nieuw, maar focus op eenvoud en snelheid!

Ziet er veelbelovend uit, eindelijk een VPN-oplossing van dezelfde klasse als IPSec, maar tegelijk niet zo complex om te configureren. Een beetje de Let's Encrypt van de VPN wereld. Dit zou wel eens de opvolger van IPSec en de belangrijkste VPN oplossing van het volgend decennium kunnen worden.

Volgens mij is het wel nog wat te vroeg om dit nu al volop in productieomgevingen te zetten. Een stable release is er nog niet. De adoptie is nog zeer beperkt, waardoor er nog wel wat problemen/verbeteringen zullen uitkomen eenmaal er meer gebruikers bijkomen, een fase die IPSec al doorlopen heeft. En het probleem met clients die je moet downloaden is dat dat allemaal niet native draait in het systeem (itt IPSec) en dus nooit zo snel zal zijn. Vanaf het native beschikbaar komt is het zeker te overwegen. Linux zou het in versie 5.6 van de kernel toevoegen, die volgend jaar uitkomt.

Is strongswan dan de enige/beste optie voor op een Debian server?

Niet de enige, IMHO wel de beste. Overigens doet StrongSwan enkel maar het lichte IKEv2 gedeelte in Linux, zijnde het beheer van de sleutels voor de encryptie. Het intensieve IPSec werk zelf gebeurt native in de kernel.

Volgens wat ik lees wordt het in moderne OS'sen ondersteund, maar niet op W10?

Windows 10 heeft zowel native IPSec als IKEv2, dus geen aparte tool nodig. Heb geen Windows, maar het lijkt dat het erg gelijkaardig is aan macOS. Naar netwerkconfiguratie gaan, daar VPN kiezen, en dan je een IKEv2 configuratie toevoegen.

Ook zie ik op de strongswan site dat er een app is voor Android, werkt het daar dan ook niet out of the box?

Jawel, maar pas sinds Android 6 (denk ik). Android 4 iig niet. StrongSwan ondersteunt wel Android 4 en 5, dus voor die versies is dat een oplossing.

[BertG3]

Wireguard zou ik inderdaad nog niet aanraden. Is nog volop in development en nog niet echt stabiel. Heb het zelf bij wijze van test eens opgezet en werkte wel goed.

OpenVPN zou normaal niet echt moeilijk moeten zijn om op te zetten. Er is een heel gekend script dat bruikbaar is voor mensen die zelfs weinig van IT afweten. Zou aanraden deze nog 's te testen. Zou normaal zeker moeten werken https://github.com/Angristan/OpenVPN-install

[GuntherDW]

Ik denk dat hij inderdaad wat verkeerd gelezen heeft. IKEv2 werkt wel op Windows (waarschijnlijk), maar dan enkel met certs, niet met "enkel" een PSK.
Het hele cert gebeuren maakt het natuurlijk wel veiler en makkelijker te onderhouden voor grotere omgevingen natuurlijk.

Het is een beetje hetzelfde principe met OpenVPN, daar kan je ook "enkel" u/p vragen of server cert en client cert.
Als je voor het 2de gaat kan je iets makkelijker managen als er een cert uitlekt. Alsook is het minder makkelijk te bruteforcen natuurlijk.

[CCatalyst]

Een cert spoofen is onbegonnen werk. Bovendien kan je certs "pinnen" aan bv een IP adres waardoor een gestolen certificaat waardeloos is als ze geen connectie kunnen initieren vanaf dat IP.

Risico's zitten hem eerder in niet-geautoriseerde toegang tot de CA infrastructuur waar ze dan gewoon een nieuw cert aanmaken, dat aanbieden aan de IKEv2 en zo zijn ze meteen binnen natuurlijk, tenzij IPSec enkel maar connecties van gekende IP's aanvaardt. Maar ook dat is niet eenvoudig. Eerst moeten ze al kunnen uitvinden waar de CA infrastructuur staat, wat totaal los van de IPsec infrastructuur kan staan. Als de CA offline staat, stop het hier al. Indien online, moeten ze nog op de juiste account kunnen binnen raken op het systeem. Dan moeten ze nog het paswoord weten om de private key te kunnen gebruiken. En alle X.509v3 parameters weten die IKEv2 vereist. En hopen dat er geen alert gestuurd wordt als een nieuw cert gegenereerd wordt, anders zijn ze meteen gezien.

Als je met state actors te doen hebt is dat allemaal in principe mogelijk en zeker ook al gebeurd, maar dan zal je (hopelijk) ook niet op Userbase komen posten voor VPN advies. Daarvan, tenzij men het echt op jou gemunt heeft, gaan de bots uw VPN al snel links laten liggen tvv servers die met een simpele PSK werken en ze enkel maar moeten bruteforcen. De fietsendief kiest ook niet de fiets waar 3 verschillende types van sloten aan hangen, wel de fiets met enkel maar het simpel cijferslot.

[Ernie]

OpenVPN zou normaal niet echt moeilijk moeten zijn om op te zetten. Er is een heel gekend script dat bruikbaar is voor mensen die zelfs weinig van IT afweten. Zou aanraden deze nog 's te testen. Zou normaal zeker moeten werken https://github.com/Angristan/OpenVPN-install

Heb dit geprobeerd maar loop vast op een tun/tap foutmelding die ik maar niet kreeg opgelost ondanks dat daar veel over te vinden is, inclusief de oplossing, maar dat werkte niet.

Nu dus met Strongswan aan de slag gegaan, met deze howto, exact gevolgd maar ook daar weer nieuwe hindernissen...
Server lijkt OK te zijn, heb het certificaat geïmporteerd en bij het verbinden duurt het behoorlijk lang vooraleer er een error 800 melding verschijnt.

Mijn client is een W8.1 en heb daar in de verbinding met de security settings gegoocheld tussen Automatic en IKEv2, krijg dan "13868 error: policy match error"
Nu maak ik me wel de bedenking dat ik evt iets fout heb gedaan mbt het server adres: ik heb nl telkens het LAN IP gebruikt in de configuratie v/d server, ook voor het certificaat.
Vermoed dat dit al niet OK is - was laat gisteren...

Verder heb ik poorten 500 en 4500 UDP geforward naar LAN IP v/d server op de remote BBox maar als ik scan krijg ik alleen 500 als open te zien.
Dit is de status v/d server:

Code: Selecteer alles

root@v-vpn:~# systemctl status strongswan
* strongswan.service - strongSwan IPsec IKEv1/IKEv2 daemon using ipsec.conf
   Loaded: loaded (/lib/systemd/system/strongswan.service; enabled; vendor preset: enabled)
   Active: active (running) since Fri 2019-12-20 00:37:42 CET; 12h ago
 Main PID: 110 (starter)
    Tasks: 18 (limit: 4915)
   Memory: 4.0M
   CGroup: /system.slice/strongswan.service
           |-110 /usr/lib/ipsec/starter --daemon charon --nofork
           `-128 /usr/lib/ipsec/charon --debug-ike 1 --debug-knl 1 --debug-cfg 0

Dec 20 12:40:40 v-vpn charon[128]: 12[IKE] received MS-Negotiation Discovery Capable vendor ID
Dec 20 12:40:40 v-vpn charon[128]: 12[IKE] received Vid-Initial-Contact vendor ID
Dec 20 12:40:40 v-vpn charon[128]: 12[ENC] received unknown vendor ID: 01:52:8b:bb:c0:06:96:12:18:49:ab:9a:1c:5b:2a:51:00:
Dec 20 12:40:40 v-vpn charon[128]: 12[IKE] <mijn WAN IP> is initiating an IKE_SA
Dec 20 12:40:40 v-vpn charon[128]: 12[IKE] <mijn WAN IP> is initiating an IKE_SA
Dec 20 12:40:40 v-vpn charon[128]: 12[IKE] local host is behind NAT, sending keep alives
Dec 20 12:40:40 v-vpn charon[128]: 12[IKE] remote host is behind NAT
Dec 20 12:40:40 v-vpn charon[128]: 12[IKE] received proposals unacceptable
Dec 20 12:40:40 v-vpn charon[128]: 12[ENC] generating IKE_SA_INIT response 0 [ N(NO_PROP) ]
Dec 20 12:40:40 v-vpn charon[128]: 12[NET] sending packet: from 192.168.1.103[500] to <mijn WAN IP>[500] (36 bytes)

[ITnetadmin]

Hij vloekt duidelijk op een proposal mismatch in de handshake, maw zender en ontvanger hebben minstens 1 parameter in hun proposal die niet overeenkomt.

Ik raad overigens niet aan om certs aan IPs te verbinden, tenzij je fixed IPs hebt.
Anders kan je opnieuw beginnen elke keer je IP verandert.

[CCatalyst]

Deze is het probleem:

received proposals unacceptable

En dat ligt dus aan die complexe configuratie, die ik als con heb opgesomd.

Enfin, de server is geconfigureerd om een of meerdere ciphers te aanvaarden voor encryptie, authenticatie, evt ook de pseudo-random functie en perfect forward secrecy. Ook als je dit niet expliciet geconfigureerd hebt, dan nog is er een "default" selectie van toepassing.

Voor de client geldt hetzelfde. Die is ook geconfigureerd of volgt z'n default selectie.

Jouw probleem is dat de client dus voor een of meer parameters, ciphers voorstelt die de server niet aanvaardt. Omdat ze niet geconfigureerd zijn, of omdat ze niet in de default selectie zitten bij gebrek aan configuratie.

Je moet de ciphers dus aanpassen in de client zodat ze matchen met wat de server wil aanvaarden. Of omgekeerd, je kan ook de server aanpassen ifv de client

Mits het configureren van meer debug output zou je normaal wel moeten zien wat de client voorstelt, wat de server verwacht, en dus waar de mismatch zit.

[honda4life]

Wel even de opmerking.
Bij gebruik OpenVPN heb ik de indruk dat Android dit niet meer als een verbinding met "beperkt dataverbruik" ziet, misschien iets om te testen / rekening mee te houden?

[Ernie]

Nu heb ik dus de LAN IP's die ik had ingevuld vervangen door een dyndns hostname.
Voor die 13868 error heb ik het volgende gedaan:

Code: Selecteer alles

The solution was to create a windows registry key:
Path: HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\Rasman\Parameters
Key: NegotiateDH2048_AES256  
Type: DWORD 32bit
Value: 1 

Deze is het probleem:

received proposals unacceptable

Hiermee lijkt dat probleem van de baan, nieuwe hindernis: error 809.
Kan het zijn dat dit komt omdat die 4500 UDP poort niet open lijkt te zijn? (zie nu dat dit OK is)

Oh ja, volgens die howto die ik hierboven heb aangehaald hebben ze het over '4096-bit RSA'.
Is dan die 'Key: NegotiateDH2048_AES256' niet OK?

Server status:

Dec 20 23:03:44 v-vpn charon[748]: 10[IKE] EAP-Identity request configured, but not supported
Dec 20 23:03:44 v-vpn charon[748]: 10[IKE] loading EAP_MSCHAPV2 method failed
Dec 20 23:03:44 v-vpn charon[748]: 10[IKE] peer supports MOBIKE
Dec 20 23:03:44 v-vpn charon[748]: 10[ENC] generating IKE_AUTH response 1 [ IDr EAP/FAIL ]
Dec 20 23:03:44 v-vpn charon[748]: 10[NET] sending packet: from 192.168.1.103[4500] to <mijn WAN IP>[4500] (108 bytes)
Dec 20 23:08:31 v-vpn charon[748]: 07[NET] received packet: from <mijn WAN IP>[33981] to 192.168.1.103[500] (192 bytes)
Dec 20 23:08:31 v-vpn charon[748]: 07[ENC] parsed ID_PROT request 0 [ SA ]
Dec 20 23:08:31 v-vpn charon[748]: 07[IKE] no IKE config found for 192.168.1.103...<mijn WAN IP>, sending NO_PROPOSAL_CHOS
Dec 20 23:08:31 v-vpn charon[748]: 07[ENC] generating INFORMATIONAL_V1 request 1686437897 [ N(NO_PROP) ]
Dec 20 23:08:31 v-vpn charon[748]: 07[NET] sending packet: from 192.168.1.103[500] to <mijn WAN IP>[33981] (40 bytes)

Update: ben een stap verder geraakt en heb nu verbinding!
De oplossing was om 'libcharon-extra-plugins' te installeren.

Alleen heb ik nu enkel verbinding met de server maar kan aan geen enkele host er achter.
Iemand een idee of die howto voorziet dat dit moet kunnen of waar te zoeken?

Update 2: 'sysctl net.ipv4.ip_forward=1' in '/etc/sysctl.conf' brengt geen soelaas.
Er is geen firewall actief op die server.
Iemand een tip?

1) De netwerklocatie van die VPN verbinding op mijn W8.1 client was 'Public': is dat normaal of kan/mag/moet die naar 'Private' gewijzigd worden voor andere dingen dan mijn client firewall?
2) Is het normaal dat de VPN server adapter in een apart subnet zit, kan/mag die niet gewoon in het bestaande zitten?

[Sasuke]

Op je bbox maak je een static route voor het vpn subnet naar het IP van je vpnserver.

[Ernie]

Ik zou sowieso al niet goed weten hoe maar nog meer: kan dat op een BBox3?

[ITnetadmin]

Goeie vraag; geen idee.

Maar wat/hoe is eenvoudiger: bij een static route zeg je "ip range 192.168.3.0/24 is bereikbaar via toestel 192.168.1.2", bv.
Waarbij je dan je vpn range invult en het ip van het toestel dat de vpn opzet.

Elke pc heeft minstens 1 ingevulde route (naast al de automatisch gecreeerde door de interface).
Dat noemt in windows de "default gateway", cisco is accurater wanneer ze het de "gateway of last resort" noemen.
Dat is basically de setting die zegt "voor alle andere netwerken dan degene waar je inzit, kan je de pakketjes afleveren aan dat IP, die weet wel wat ermee gedaan".
Een static route toevoegen is eigenlijk zoals een firewall rule; je gaat zeggen "voor dat specifiek netwerk lever je de pakketjes af aan dit IP adres" ipv aan de default gateway.

Een goeie tip bij het debuggen is: versta dat pakketjes one-way traffic zijn.
Neem bv een ping. Dan stuur je een ping pakketje naar een tweede pc, en die stuurt een ping reply terug.
Om dit te doen werken zijn 2 dingen nodig (wel, effe aannemen dat er geen firewalls ofzo in de weg staan): de eerste pc moet weten aan wie hij de ping mag afleveren zodat die op zijn bestemming geraakt, en de tweede pc moet weten hoe hij zijn replu terugstuurt naar pc1.
Dit kan hij echter niet afleiden uit het ping pakketje zelf, IP routing is enkel-richting verkeer; beide kanten moeten dus onafhankelijk van mekaar hun weg weten te vinden.
De meeste denkfouten bij IP routing worden gemaakt wanneer je ervan uitgaat dat als pc1 pc2 kan bereiken, pc2 ook pc1 kan terugvinden; ook ik maak die fout af en toe nog wel ns bij haast.

[Ernie]

Na een groot deel van het weekend te zoeken, proberen, vooral door eliminatie achter de oorzaak te komen ben ik weer wat verder.

Op je bbox maak je een static route voor het vpn subnet naar het IP van je vpnserver.

Bedankt voor de tip/hulp, doch gaat dit niet en lag het probleem daar niet.
Zie ook dit topic: Statische route BBOX3

@ITnetadmin: dank je voor je begrijpbare verduidelijking!

Het probleem zit hem, denk ik, in de left/right configuratie van de ipsec.conf file; ik had dat overgenomen van die howto hierboven.
In de veel van die guides worden dubbelzinnige termen gebruikt die voor een kenner waarschijnlijk geen probleem vormen + wordt dikwijls niet duidelijk gemaakt dat bepaalde settings, en vooral dan ip's, vanuit eigen situatie specifiek zijn of noodzakelijk. Voor een leek in die materie is dat dan niet duidelijk.
Vandaar oa mijn vraag 'Is het normaal dat de VPN server adapter in een apart subnet zit, kan/mag die niet gewoon in het bestaande zitten?'

Als ik op mijn W8.1 client naar de details van de VPN adapter kijk heeft die het LAN IP van de remote BBox, subnet = 255.255.255.255, geen gateway maar wel het remote DNS LAN IP.
De settings op mijn client forceren doet er niets aan af. (?worden overschreven bij het verbinden?)

Dit is de inhoud van ipsec.conf:

Code: Selecteer alles

config setup
   charondebug="ike 1, knl 1, cfg 0"
    uniqueids=no

conn ikev2-vpn
    auto=add
    compress=no
    type=tunnel
    keyexchange=ikev2
    fragmentation=yes
    forceencaps=yes
    dpdaction=clear
    dpddelay=300s
    rekey=no
    left=%any
    leftid=@<FQDN> (dyndns host remote WAN)
    leftcert=server-cert.pem
    leftsendcert=always
    leftsubnet=0.0.0.0/0
    right=%any
    rightid=%any
    rightauth=eap-mschapv2
    rightsourceip=192.168.1.0/24 (remote subnet. Daarom dat mijn VPN adapter IP heeft dat hetzelfde is als remote BBox?)
    rightdns=192.168.1.3 (remote DNS)
    rightsendcert=never
    eap_identity=%identity

Client
Netwerk: 172.16.0.0/24
GW: 172.16.0.1
DNS: 172.16.0.3

Server
Netwerk: 192.168.1.0/24
GW: 192.168.1.1
DNS: 192.168.1.3
DHCP: .40 - .65

Kan iemand van jullie me een zetje geven in de juiste richting?
Alvast bedankt!

[CCatalyst]

Vandaar oa mijn vraag 'Is het normaal dat de VPN server adapter in een apart subnet zit, kan/mag die niet gewoon in het bestaande zitten?'

Voor route-based IPSec, zal een router waar bv al een 192.168.1/24 subnet zit, geen aparte pseudo interface voor IPsec kunnen maken met een IP dat in dat subnet zit want dan heb je een overlap. Dus dan zou je client een pakket sturen op de VPN met src 192.168.1.x dst xxxx, dat vervolgens verder geroute wordt aan de overkant, en replies gaan dan gaan naar 192.168.1.x wat niet de IPsec interface zal zijn maar wel bv een LAN achter de router, en dan wordt het gedropt want niemand zal daar luisteren naar dat IP (en indien wel zal de poort niet open staan).

Policy-based IPSec, het zou dan volgens mij wel werken voor verkeer dat van buiten dat subnet komt en langs de router passeert, maar verkeer vanop het 192.168.1.x LAN zou gewoon een ARP sturen wat niet door de traffic selector opgepikt zou worden.

Het kan wel met bv dubbele NAT oid, maar is af te raden. Alle L2 broadcasts gaan dan bv over de VPN gaan, en dan zit je ook met een IP dat je DHCP server aan de andere kant niet mag uitdelen, etc. Het leidt vooral tot verwarring.

Kan iemand van jullie me een zetje geven in de juiste richting?

Probeer route-based IPSec ipv policy-based: https://wiki.strongswan.org/projects/st ... teBasedVPN
Configureer een VTI (ipsec0)
Gebruik een privaat subnet dat buiten het subnet van een bestaande interface valt voor de pool (of "Virtual IP" zoals StrongSwan het noemt).
Voeg een static route toe naar het subnet van de pool/Virtual IP via ipsec0.

Noot, als het de bedoeling is dat verkeer vanaf de client via de server naar een publiek IP gaat (het internet dus) moet je ook zien dat de server het privaat IP van de client laat NATten.

Als het niet lukt zou ik aanraden om met behulp van tcpdump de stroom van de pakketten te volgen om te achterhalen waar ze gedropt worden.