[Debian] bridging over vpn

[UltraSub]

Omdat ik samen met een maat gebruik wil kunnen maken van gezamenlijke shares, wil ik gaan bridgen. Eerst wilden we dit doen via een wifi link wat qua afstand wel zou gaan, maar qua obstakels zal het moeilijk worden. We hebben geen zin om voor honderden euros te gaan investeren in apparatuur, om vervolgens toch te blijven zitten met een instabiele link.

Het was iig al zeker dat ook hij hier een debian bak voor zou moeten krijgen, welke hem voorziet van alle gemakken thuis, zoals mail, ftp, dynamic dhcp, enz. Iets wat bij mij al jaren perfect draait. Hij wilde dat ook wel, dus heb ik hem zo'n bak gebouwd. Die is nu klaar, moet alleen nog bij hem geimplementeerd en afgeconfigureerd worden. Zodoende kwam ineens bij mij het idee op om die twee bakken via het net en vpn te gaan bridgen. Ok, niet snel, maar het werkt op zich wel. Plus dat het leuk is om mee te stoeien

Nou ben ik op zich niet zo'n kei in networking en de routering die daarbij hoort, dus ging ik eens op zoek naar verschillende howto's voor een projectje als dit. Ik kom daarbij een hoop vpn oplossingen tegen, varierend van hard to implement, tot vrij makkelijk voor elkaar te krijgen.
Echter ik ben wel voornemens de boel zo secure mogelijk te krijgen, en van wat ik overal lees, schijnt daarvoor toch IPsec de aangewezen software te zijn. Vervolgens zie ik in de howto's dat meestal twee bakken worden gebridged, óf één server, waarop andere computers kunnen inloggen via vpn, maar waarbij niet gebridged wordt.
Omdat ik verwacht dat binnen nu en een jaar nog een maat een debian bak krijgt, en die wss ook wel zal willen bridgen, voorzie ik toch wel wat probleempjes, met het "simpel" bridgen van twee servers..

Daarom zou ik dus graag willen dat ik zelf een vpn server draai, en dat iedere (in dit geval debian server) die daar via vpn op connect, gebridged wordt. Met andere woorden, we krijgen een stervormig netwerk via het internet. Allemaal mooi en aardig, maar we willen wel allemaal onze eigen dhcp servers blijven gebruiken, dus de lokale ipranges in ieder netwerk moeten verschillend blijven (192.168.0.*, 192.168.1.*, 192.168.2.* enz). Eigenlijk ben ik nu al gewoon een paar dagen aan het zoeken op google, en het spitten in howto's, maar ik merk dat ik langzaam door de bomen het bos niet meer zie, en ik de draad kwijt aan het raken ben. Ik snap ook niet meer hoe dat netjes gerouteerd zou moeten worden

Ik weet van mezelf dat ik hier wel uit zou moeten kunnen komen als ik een begin heb, met wat belangrijke aangrijppunten. Kortom, kan iemand me tips geven, of naar een howto pointeren waar iets als dit wordt beschreven?

(wellicht moet dit topic in network troubleshooting, maar ik dacht, er is nog niets te troubleshooten, en ik wilde het graag Debian specific houden. Dat er een overlap is, sja.... )

[Aike]

Wat is nou precies je vraag? Hier is een heel topic over VPN onder linux: Animocheck NOS GoTVPN.

Niet om vervelend te zijn, maar zelf zou ik het heel anders aanpakken. VPN is namelijk best een lastige setup om een paar bestandjes te delen. Een shfs mount is volgens mij veel geschikter:

Shfs is a simple and easy to use Linux kernel module which allows you to mount remote filesystems using a plain shell (ssh) connection. When using shfs, you can access all remote files just like the local ones, only the access is governed through the transport security of ssh. Shfs supports some nice features including file caching for access speedup and persistent connections (reconnect after ssh dies).

[UltraSub]

Hmm... das een goeie idd. Had ik nog niet bij stil gestaan dat als het puur om sharen gaat dat het ook op andere manieren kan
Maar goed, het was natuurlijk wel heel mooi als je gewoon thuis op je eigen netwerk zit, en je kan ook alles met "zijn" netwerk, alsof je daar er op zit. You name it, remote desktop en zo, zonder firewalling enz. om maar een mini voorbeeld te noemen.
Maar voor de snelle oplossing, en waarschijnlijk de makkelijkste, you're right. Ga ik volgende week eens naar kijken. Bedankt!

[_JGC_]

Gewoon elk een eigen range uitzoeken, LANs met OpenVPN aanelkaar knopen en gewoon routing gebruiken, heb je geen enkel probleem. Je kunt met OpenVPN zowat elk denkbaar OS aan elkaar knopen, ik heb het werkend tussen OpenBSD en Linux, maar ook tussen Linux en Windows XP.

[UltraSub]

Volgens mij is dit wel aardig in de richting die ik bedoel:
Joining Networks with OpenVPN
Om twee netwerken te bridgen lijkt dit idd een hele makkelijke setup. Is dit een secure oplossing? Een persistent tunnel met OpenVPN op deze manier over het internet?

/edit
Ow, beide servers draaien dus een dynamic dhcp, is het mogelijk dat beide dhcp servers de hostnames op 2 plaatsen bijwerken? Zodat als mijn maat een ipadres van zijn dhcp toegewezen krijgt, ik zijn hostnames kan gebruiken om zijn ip's te resolven?
Eén dhcp server voor beide netwerken zou natuurlijk kunnen, maar lijkt me niet handig, omdat het over een internet verbinding gaat. Niet voor de snelheid, maar tis wel rot als internet er uit ligt

[ Voor 42% gewijzigd door UltraSub op 27-12-2005 13:22 ]

[UltraSub]

Shit, vrij nutteloze howto wat ik hier boven zei.
Net gedaan, werkt dus niet zo simpel als het daar verteld wordt.

Nou heb ik weer een uurtje googlen achter de rug, en het is voor mij duidelijk geworden dat ik toch echt een goede howto te pakken moet zien te krijgen, anders ga ik dit niet voor elkaar krijgen
OpenVPN lijkt een geweldig tool, echter heeft nog steeds een gebrek aan goede fool-proof howtos zo te zien.

/edit
@Aike:
Net ge-experimenteerd met sshfs. Werkt mooi, alleen kan ik er voor mijn doeleinden niets mee.
Ik gebruik rsync snapshot style backups, en blijkbaar mag rsync wel schrijven in zo'n ssfhs share, maar geen chown doen om de rechten hetzelfde te zetten als op het source systeem.
Op dit moment nutteloos dus voor backup doeleinden. Daar voor zal ik dus toch moeten gaan kijken naar vpn achtige oplossingen.

[ Voor 34% gewijzigd door UltraSub op 01-01-2006 18:17 ]

[_JGC_]

Aan je user icon te zien gebruik je Debian
apt-get install openvpn, vervolgens even een kijkje nemen in /usr/share/doc/openvpn/examples. Het makkelijkste is om daar de client en server configfiles van te nemen, de serverconfig zet je op de machine die een statische hostname heeft of die het minst vaak van IP verandert. Vervolgens gebruik je dat easy-rsa ding om keys te genereren, staat allemaal gewoon op de OpenVPN website beschreven hoe je dat doet.

Ik heb het een tijdje terug ook uitgezocht, hooguit een uurtje werk en ik genereer zo een extra clientkey met bijbehorende configfile met dat easy-rsa ding van OpenVPN

[Verwijderd]

http://www.debian-administration.org/articles/157

Met deze howto zal het je zeker lukken

[ Voor 8% gewijzigd door Verwijderd op 01-01-2006 20:17 ]

[UltraSub]

Ok jongens, ik kijk er morgenmiddag nog eens naar
Bedankt...

[UltraSub]

Ik heb er eens wat werk in gestoken, en ik heb een server-client vpn draaien, echter ik krijg routering niet voor elkaar. Ik kan wel van de client naar de server pingen, maar niet andersom

Wat doe ik.....
Eerst server starten:

code:

viper:/etc/openvpn# ./openvpn-startup.sh 
viper:/etc/openvpn# cat openvpn.log 
Tue Jan  3 19:44:56 2006 OpenVPN 2.0.5 i486-pc-linux-gnu [SSL] [LZO] [EPOLL] built on Nov  7 2005
Tue Jan  3 19:44:57 2006 Diffie-Hellman initialized with 1024 bit key
Tue Jan  3 19:44:57 2006 TLS-Auth MTU parms [ L:1542 D:138 EF:38 EB:0 ET:0 EL:0 ]
Tue Jan  3 19:44:57 2006 TUN/TAP device tun0 opened
Tue Jan  3 19:44:57 2006 /sbin/ifconfig tun0 10.90.90.1 pointopoint 10.90.90.2 mtu 1500
Tue Jan  3 19:44:57 2006 /sbin/route add -net 10.90.90.0 netmask 255.255.255.0 gw 10.90.90.2
Tue Jan  3 19:44:57 2006 Data Channel MTU parms [ L:1542 D:1450 EF:42 EB:135 ET:0 EL:0 AF:3/1 ]
Tue Jan  3 19:44:57 2006 chroot to '/etc/openvpn' and cd to '/' succeeded
Tue Jan  3 19:44:57 2006 GID set to nogroup
Tue Jan  3 19:44:57 2006 UID set to nobody
Tue Jan  3 19:44:57 2006 UDPv4 link local (bound): [undef]:1194
Tue Jan  3 19:44:57 2006 UDPv4 link remote: [undef]
Tue Jan  3 19:44:57 2006 MULTI: multi_init called, r=256 v=256
Tue Jan  3 19:44:57 2006 IFCONFIG POOL: base=10.90.90.4 size=62
Tue Jan  3 19:44:57 2006 IFCONFIG POOL LIST
Tue Jan  3 19:44:57 2006 server.eenip.net,10.90.90.4
Tue Jan  3 19:44:57 2006 Initialization Sequence Completed
Tue Jan  3 19:45:03 2006 MULTI: multi_create_instance called
Tue Jan  3 19:45:03 2006 xx.xx.xx.xxx:1194 Re-using SSL/TLS context
Tue Jan  3 19:45:03 2006 xx.xx.xx.xxx:1194 LZO compression initialized
Tue Jan  3 19:45:03 2006 xx.xx.xx.xxx:1194 Control Channel MTU parms [ L:1542 D:138 EF:38 EB:0 ET:0 EL:0 ]
Tue Jan  3 19:45:03 2006 xx.xx.xx.xxx:1194 Data Channel MTU parms [ L:1542 D:1450 EF:42 EB:135 ET:0 EL:0 AF:3/1 ]
Tue Jan  3 19:45:03 2006 xx.xx.xx.xxx:1194 Local Options hash (VER=V4): '530fdded'
Tue Jan  3 19:45:03 2006 xx.xx.xx.xxx:1194 Expected Remote Options hash (VER=V4): '41690919'
Tue Jan  3 19:45:03 2006 xx.xx.xx.xxx:1194 TLS: Initial packet from xx.xx.xx.xxx:1194, sid=b8bc4dbf 7619b761
Tue Jan  3 19:45:04 2006 xx.xx.xx.xxx:1194 VERIFY OK: depth=1, /C=NL/ST=NA/L=BISHKEK/O=UltraSub/CN=server.eenip.net/emailAddress=[e-mail]
Tue Jan  3 19:45:04 2006 xx.xx.xx.xxx:1194 VERIFY OK: depth=0, /C=NL/ST=NA/O=UltraSub/CN=server.eenip.net/emailAddress=[e-mail]
Tue Jan  3 19:45:04 2006 xx.xx.xx.xxx:1194 Data Channel Encrypt: Cipher 'BF-CBC' initialized with 128 bit key
Tue Jan  3 19:45:04 2006 xx.xx.xx.xxx:1194 Data Channel Encrypt: Using 160 bit message hash 'SHA1' for HMAC authentication
Tue Jan  3 19:45:04 2006 xx.xx.xx.xxx:1194 Data Channel Decrypt: Cipher 'BF-CBC' initialized with 128 bit key
Tue Jan  3 19:45:04 2006 xx.xx.xx.xxx:1194 Data Channel Decrypt: Using 160 bit message hash 'SHA1' for HMAC authentication
Tue Jan  3 19:45:04 2006 xx.xx.xx.xxx:1194 Control Channel: TLSv1, cipher TLSv1/SSLv3 DHE-RSA-AES256-SHA, 1024 bit RSA
Tue Jan  3 19:45:05 2006 xx.xx.xx.xxx:1194 [server.eenip.net] Peer Connection Initiated with xx.xx.xx.xxx:1194
Tue Jan  3 19:45:05 2006 server.eenip.net/xx.xx.xx.xxx:1194 MULTI: Learn: 10.90.90.6 -> server.eenip.net/xx.xx.xx.xxx:1194
Tue Jan  3 19:45:05 2006 server.eenip.net/xx.xx.xx.xxx:1194 MULTI: primary virtual IP for server.eenip.net/xx.xx.xx.xxx:1194: 10.90.90.6
Tue Jan  3 19:45:06 2006 server.eenip.net/xx.xx.xx.xxx:1194 PUSH: Received control message: 'PUSH_REQUEST'
Tue Jan  3 19:45:06 2006 server.eenip.net/xx.xx.xx.xxx:1194 SENT CONTROL [server.eenip.net]: 'PUSH_REPLY,route 10.90.90.1,ping 10,ping-restart 120,ifconfig 10.90.90.6 10.90.90.5' (status=1)

ifconfig tun0:

code:

viper:/etc/openvpn# ifconfig tun0
tun0      Link encap:UNSPEC  HWaddr 01-40-F4-5F-01-40-C8-FC-00-00-00-00-00-00-00-00  
          inet addr:10.90.90.1  P-t-P:10.90.90.2  Mask:255.255.255.255
          UP POINTOPOINT RUNNING NOARP MULTICAST  MTU:1500  Metric:1
          RX packets:0 errors:0 dropped:0 overruns:0 frame:0
          TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:100 
          RX bytes:0 (0.0 b)  TX bytes:0 (0.0 b)

Dan de client:

code:

spar:/etc/openvpn# cat openvpn.log 
Tue Jan  3 19:44:58 2006 OpenVPN 2.0.5 i486-pc-linux-gnu [SSL] [LZO] [EPOLL] built on Nov  7 2005
Tue Jan  3 19:44:58 2006 IMPORTANT: OpenVPN's default port number is now 1194, based on an official port number assignment by IANA.  OpenVPN 2.0-beta16 and earlier used 5000 as the default port.
Tue Jan  3 19:44:58 2006 LZO compression initialized
Tue Jan  3 19:44:58 2006 Control Channel MTU parms [ L:1542 D:138 EF:38 EB:0 ET:0 EL:0 ]
Tue Jan  3 19:44:58 2006 Data Channel MTU parms [ L:1542 D:1450 EF:42 EB:135 ET:0 EL:0 AF:3/1 ]
Tue Jan  3 19:44:58 2006 Local Options hash (VER=V4): '41690919'
Tue Jan  3 19:44:58 2006 Expected Remote Options hash (VER=V4): '530fdded'
Tue Jan  3 19:44:58 2006 NOTE: chroot will be delayed because of --client, --pull, or --up-delay
Tue Jan  3 19:44:58 2006 NOTE: UID/GID downgrade will be delayed because of --client, --pull, or --up-delay
Tue Jan  3 19:44:58 2006 UDPv4 link local (bound): [undef]:1194
Tue Jan  3 19:44:58 2006 UDPv4 link remote: xx.xx.xx.xx:1194
Tue Jan  3 19:44:58 2006 TLS: Initial packet from xx.xx.xx.xx:1194, sid=e2056440 6ec0fa08
Tue Jan  3 19:44:58 2006 VERIFY OK: depth=1, /C=NL/ST=NA/L=BISHKEK/O=UltraSub/CN=server.eenip.net/emailAddress=[e-mail]
Tue Jan  3 19:44:58 2006 VERIFY OK: nsCertType=SERVER
Tue Jan  3 19:44:58 2006 VERIFY OK: depth=0, /C=NL/ST=NA/O=UltraSub/CN=server.eenip.net/emailAddress=[e-mail]
Tue Jan  3 19:44:59 2006 Data Channel Encrypt: Cipher 'BF-CBC' initialized with 128 bit key
Tue Jan  3 19:44:59 2006 Data Channel Encrypt: Using 160 bit message hash 'SHA1' for HMAC authentication
Tue Jan  3 19:44:59 2006 Data Channel Decrypt: Cipher 'BF-CBC' initialized with 128 bit key
Tue Jan  3 19:44:59 2006 Data Channel Decrypt: Using 160 bit message hash 'SHA1' for HMAC authentication
Tue Jan  3 19:44:59 2006 Control Channel: TLSv1, cipher TLSv1/SSLv3 DHE-RSA-AES256-SHA, 1024 bit RSA
Tue Jan  3 19:44:59 2006 [server.eenip.net] Peer Connection Initiated with xx.xx.xx.xx:1194
Tue Jan  3 19:45:00 2006 SENT CONTROL [server.eenip.net]: 'PUSH_REQUEST' (status=1)
Tue Jan  3 19:45:00 2006 PUSH: Received control message: 'PUSH_REPLY,route 10.90.90.1,ping 10,ping-restart 120,ifconfig 10.90.90.6 10.90.90.5'
Tue Jan  3 19:45:00 2006 OPTIONS IMPORT: timers and/or timeouts modified
Tue Jan  3 19:45:00 2006 OPTIONS IMPORT: --ifconfig/up options modified
Tue Jan  3 19:45:00 2006 OPTIONS IMPORT: route options modified
Tue Jan  3 19:45:00 2006 TUN/TAP device tun0 opened
Tue Jan  3 19:45:00 2006 /sbin/ifconfig tun0 10.90.90.6 pointopoint 10.90.90.5 mtu 1500
Tue Jan  3 19:45:00 2006 /sbin/route add -net 10.90.90.1 netmask 255.255.255.255 gw 10.90.90.5
Tue Jan  3 19:45:00 2006 chroot to '/etc/openvpn' and cd to '/' succeeded
Tue Jan  3 19:45:00 2006 GID set to nogroup
Tue Jan  3 19:45:00 2006 UID set to nobody
Tue Jan  3 19:45:00 2006 Initialization Sequence Completed

ifconfig tun0:

code:

spar:/etc/openvpn# ifconfig tun0
tun0      Link encap:UNSPEC  HWaddr 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00  
          inet addr:10.90.90.6  P-t-P:10.90.90.5  Mask:255.255.255.255
          UP POINTOPOINT RUNNING NOARP MULTICAST  MTU:1500  Metric:1
          RX packets:0 errors:0 dropped:0 overruns:0 frame:0
          TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:100 
          RX bytes:0 (0.0 b)  TX bytes:0 (0.0 b)

Openvpn maakt vervolgens routes aan en ik heb dus dit:
Aan de serverkant:

code:

viper:/etc/openvpn# route
Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
10.90.90.2      *               255.255.255.255 UH    0      0        0 tun0
192.168.0.0     *               255.255.255.0   U     0      0        0 eth0
10.90.90.0      10.90.90.2      255.255.255.0   UG    0      0        0 tun0
default         ubr4-ca3-0-sec. 0.0.0.0         UG    0      0        0 eth1

Aan de client kant:

code:

spar:/etc/openvpn# route
Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
10.90.90.1      10.90.90.5      255.255.255.255 UGH   0      0        0 tun0
10.90.90.5      *               255.255.255.255 UH    0      0        0 tun0
192.168.1.0     *               255.255.255.0   U     0      0        0 eth0
default         ubr4-ca3-0-sec. 0.0.0.0         UG    0      0        0 eth1

So far so good.
Aan de server kant heb ik lokale ipadressen in de 192.168.0.* reeks.
Aan de client kant heb ik lokale ipadressen in de 192.168.1.* reeks.
Dus gooi ik er een route op als volgt:
Aan de client kant:
route add -net 192.168.0.0 netmask 255.255.255.255 gw 10.90.90.5
Aan de server kant:
route add -net 192.168.1.0 netmask 255.255.255.255 gw 10.90.90.2

Het resultaat:
Client kant:

code:

spar:/etc/openvpn# ping 192.168.1.1
PING 192.168.1.1 (192.168.1.1) 56(84) bytes of data.
64 bytes from 192.168.1.1: icmp_seq=1 ttl=64 time=0.338 ms
64 bytes from 192.168.1.1: icmp_seq=2 ttl=64 time=0.262 ms

--- 192.168.1.1 ping statistics ---
2 packets transmitted, 2 received, 0% packet loss, time 999ms
rtt min/avg/max/mdev = 0.262/0.300/0.338/0.038 ms
spar:/etc/openvpn# route
Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
10.90.90.1      10.90.90.5      255.255.255.255 UGH   0      0        0 tun0
10.90.90.5      *               255.255.255.255 UH    0      0        0 tun0
192.168.0.0     10.90.90.5      255.255.255.255 UGH   0      0        0 tun0
192.168.1.0     *               255.255.255.0   U     0      0        0 eth0
default         ubr4-ca3-0-sec. 0.0.0.0         UG    0      0        0 eth1

Serverkant:

code:

viper:/etc/openvpn# ping 192.168.1.1
PING 192.168.1.1 (192.168.1.1): 56 data bytes

--- 192.168.1.1 ping statistics ---
1 packets transmitted, 0 packets received, 100% packet loss
viper:/etc/openvpn# route
Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
10.90.90.2      *               255.255.255.255 UH    0      0        0 tun0
192.168.1.0     10.90.90.2      255.255.255.255 UGH   0      0        0 tun0
192.168.0.0     *               255.255.255.0   U     0      0        0 eth0
10.90.90.0      10.90.90.2      255.255.255.0   UG    0      0        0 tun0
default         ubr4-ca3-0-sec. 0.0.0.0         UG    0      0        0 eth1

Sorry voor de imens lange post, maar ik zou het anders niet weten.
Doe ik nou iets fout met routes, en kijk er domweg overheen, of heb ik een situatie gebouwd waarin het never nooit gaat werken wat ik voor ogen heb?

[UltraSub]

Ben iets verder gekomen met tcpdump.
Als ik ping vanaf de server naar de client lijkt het er op (voor mij althans), dat de routering correct is en zijn werk doet, maar er komen geen replies..:

code:

viper:/etc/openvpn# tcpdump -i tun0
tcpdump: WARNING: arptype 65534 not supported by libpcap - falling back to cooked socket
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on tun0, link-type LINUX_SLL (Linux cooked), capture size 96 bytes
17:20:59.787500 IP 10.90.90.1 > spar: icmp 64: echo request seq 0
17:21:00.787752 IP 10.90.90.1 > spar: icmp 64: echo request seq 256
17:21:01.818595 IP 10.90.90.1 > spar: icmp 64: echo request seq 512
17:21:02.820416 IP 10.90.90.1 > spar: icmp 64: echo request seq 768

Vanaf de client pingen naar de server ziet er ook goed uit (maar ja, dat werkt ook ):

code:

spar:/etc/openvpn# tcpdump -i tun0
tcpdump: WARNING: arptype 65534 not supported by libpcap - falling back to cooked socket
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on tun0, link-type LINUX_SLL (Linux cooked), capture size 96 bytes
17:19:34.187467 IP 10.90.90.6 > viper: ICMP echo request, id 3434, seq 1, length 64
17:19:34.237293 IP viper > 10.90.90.6: ICMP echo reply, id 3434, seq 1, length 64
17:19:35.193855 IP 10.90.90.6 > viper: ICMP echo request, id 3434, seq 2, length 64
17:19:35.236369 IP viper > 10.90.90.6: ICMP echo reply, id 3434, seq 2, length 64

Firewalls zijn exact hetzelfde geconfigged aan beide kanten.
Beide firewalls draaien:

code:

iptables -A INPUT -i tun+ -j ACCEPT
iptables -A FORWARD -i tun+ -j ACCEPT

[ Voor 5% gewijzigd door UltraSub op 04-01-2006 17:33 ]

[_JGC_]

Je geeft de verkeerde routes op, je gebruikt nu 192.168.0.0/32 en 192.168.1.0/32, wat inhoudt dat je alleen het .0 adres zelf routeert. Je moet de /24 pakken, wat neerkomt op 192.168.0.0/255.255.255.0.

Verder kan je in de server configuratie routes pushen, iets vertelt mij ook dat jij dit doet, en dat je dit ook zo moet houden. Aan de serverkant kan je vervolgens dit proberen:

route add 192.168.1.0/24 10.8.0.1
Waar 192.168.1.0/24 het netwerk van de client is en waar 10.8.0.1 het OpenVPN IP van de server is.

Overigens hang ik gewoon alle clients in de OpenVPN range en laat ik het netwerk achter een client voor wat het is. De client pakt met routepushing toch wel de juiste interface met het juiste source IP, de server reageert gewoon terug naar dat IP.

[UltraSub]

Aha! Ok...
Ik heb het inmiddels aan de gang middels een point to point openvpn verbinding.
Straks zet ik bij die maat nog een server op, zodat een vriend van hem kan connecten met vpn in client mode, en inderdaad die krijgt gewoon de settings gepushed. Want die kant op werkte het wel.

Ik zat dus eigenlijk gewoon moeilijk te doen, met server-client stuff, terwijl het gewoon een point to point kan zijn

In ieder geval bedankt voor alle hulp!