Hallo
Ik gebruik al tijden een 'tap' bridged openVPN netwerk en dit werkte wel redelijk. Echter omdat tun/routed netwerken volgens openvpn devs zelf efficienter, beter scalen en 'sneller' zijn vond ik het tijd om ook hier naar toe up te graden. Tevens was mn tap netwerk niet helemaal probleem vrij. Omdat het 1 server met 3 remote LAN's eraan was, hadden we ook 3 DHCP servers en dat wilde nogal wel is wat raare situaties geven. Anyhow, hier mijn probleem/situatie.
Ik heb een paar LAN's die ik aan eklaar wil knopen. Namelijk 10.X.0.0/16 lans. B.v. 10.2.0.0 netmask 255.255.0.0.
De VPN IP pool is op het moment 192.168.13.0/24. (word straks waarschijnlijk 10.254.2.0/16, maar voor intiiele setup leek het me makkelijkste om duidelijk andere range hiervoor te pakken)
Een van de remote LAN's heeft als interne LAN de range 10.119.0.0/16.
Wat mijn uitendelijke doel dus is is dat een host, b.v. 10.119.0.250, 10.2.0.13 kan pingen, sshen, ftpen etc.
Tot zover heb ik het voor elkaar dat ik vanaf het 10.119.0.0/16 netwerk mn server wel kan bereiken (10.2.0.1) maar clients die hieraan hangen niet (10.2.0.13). Vanuit mn server kan ik natuurlijk wel mn clients bereiken (10.2.0.1 -> 10.2.0.13 werkt prima).
Andersom lijkt het iet wat rooskleuriger, ik kan vanuit mn server zowel 10.119.0.1 alsmede b.v. 10.119.0.250 pingen/sshen dus die kant lijkt op te werken. ergens gaat er bij het 10.2.0.0 lan iets mis.
Hier mijn openvpn server config (de relevante gedeelten)
server 192.168.13.0 255.255.255.0
client-config-dir ccd
route 10.119.0.0 255.255.0.0
push "route 10.2.0.0 255.255.0.0"
client-to-client
in ccd staat een file met de zelfde naam als de common name van het certificate en daar staat een iroute in identiek aan route, 'iroute 10.119.0.0 255.255.0.0)
ik heb ip_forward al op beide 'servers' (10.X.0.1) aangezet. Tevens bedoel ik met 'servers' min of meer de lan/dhcp servers waar de openvpn server (10.2.0.1) en client (10.119.0.1) op draaien. Hun krijgen van/via openvpn op hun tun devices de ip's 192.168.13.1 en 192.168.13.6
client to client staat aan voor de andere LAN's (clients) die straks ook geconnect worden, ik meen dat dat daarvoor o.a. nodig was in combinatie met de ccd
groetjes,
oliver
Ik gebruik al tijden een 'tap' bridged openVPN netwerk en dit werkte wel redelijk. Echter omdat tun/routed netwerken volgens openvpn devs zelf efficienter, beter scalen en 'sneller' zijn vond ik het tijd om ook hier naar toe up te graden. Tevens was mn tap netwerk niet helemaal probleem vrij. Omdat het 1 server met 3 remote LAN's eraan was, hadden we ook 3 DHCP servers en dat wilde nogal wel is wat raare situaties geven. Anyhow, hier mijn probleem/situatie.
Ik heb een paar LAN's die ik aan eklaar wil knopen. Namelijk 10.X.0.0/16 lans. B.v. 10.2.0.0 netmask 255.255.0.0.
De VPN IP pool is op het moment 192.168.13.0/24. (word straks waarschijnlijk 10.254.2.0/16, maar voor intiiele setup leek het me makkelijkste om duidelijk andere range hiervoor te pakken)
Een van de remote LAN's heeft als interne LAN de range 10.119.0.0/16.
Wat mijn uitendelijke doel dus is is dat een host, b.v. 10.119.0.250, 10.2.0.13 kan pingen, sshen, ftpen etc.
Tot zover heb ik het voor elkaar dat ik vanaf het 10.119.0.0/16 netwerk mn server wel kan bereiken (10.2.0.1) maar clients die hieraan hangen niet (10.2.0.13). Vanuit mn server kan ik natuurlijk wel mn clients bereiken (10.2.0.1 -> 10.2.0.13 werkt prima).
Andersom lijkt het iet wat rooskleuriger, ik kan vanuit mn server zowel 10.119.0.1 alsmede b.v. 10.119.0.250 pingen/sshen dus die kant lijkt op te werken. ergens gaat er bij het 10.2.0.0 lan iets mis.
Hier mijn openvpn server config (de relevante gedeelten)
server 192.168.13.0 255.255.255.0
client-config-dir ccd
route 10.119.0.0 255.255.0.0
push "route 10.2.0.0 255.255.0.0"
client-to-client
in ccd staat een file met de zelfde naam als de common name van het certificate en daar staat een iroute in identiek aan route, 'iroute 10.119.0.0 255.255.0.0)
ik heb ip_forward al op beide 'servers' (10.X.0.1) aangezet. Tevens bedoel ik met 'servers' min of meer de lan/dhcp servers waar de openvpn server (10.2.0.1) en client (10.119.0.1) op draaien. Hun krijgen van/via openvpn op hun tun devices de ip's 192.168.13.1 en 192.168.13.6
client to client staat aan voor de andere LAN's (clients) die straks ook geconnect worden, ik meen dat dat daarvoor o.a. nodig was in combinatie met de ccd
groetjes,
oliver