[OpenVPN]Subnet routing

[Zwerver]

Het volgende project ben ik al enkele weken mee bezig, met wisselend resultaat:


- Twee lokaties
- Op elke lokatie een secure en een insecure netwerk
- Een internetpijp tussen de twee lokaties
- Twee (10.247.3.233 serverside en 10.247.5.233 client) OpenVPN bakken

De twee securenetwerken moeten met elkaar verbonden worden d.m.v. de OpenVPN bakken. Omdat we een routed netwerk op ip niveau willen hebben is dit echter lastiger dan het lijkt. De volgende configfiles heb ik op dit moment:

Serverside openvpn-configfile:

code:

port 1025
proto udp
dev tun1
ca /etc/openvpn/transtrend_cacert.crt
cert /etc/openvpn/charon.crt
key /etc/openvpn/charon.key
dh /etc/openvpn/dh2048.pem
server 10.247.97.0 255.255.255.0
push "route 10.247.3.0 255.255.255.0"
route 10.247.5.0 255.255.255.0 10.247.97.2
keepalive 10 120
user nobody
group nogroup
persist-key
persist-tun
verb 3
mute 20
log-append /var/log/openvpn-secure.log
client-to-client
client-config-dir /etc/openvpn/ccd

/etc/openvpn/cdd/client

code:

ifconfig-push 10.247.97.5 10.247.97.6
route 10.247.3.0 255.255.255.0
iroute 10.247.5.0 255.255.255.0

Clientside openvpn-configfile:

code:

client
remote 10.247.3.233
port 1025
proto udp
dev tun0
ca /etc/openvpn/transtrend_cacert.crt
cert /etc/openvpn/blackbeard.crt
key /etc/openvpn/blackbeard.key
keepalive 10 120
user nobody
group nogroup
persist-key
persist-tun
verb 4
mute 20
log-append /var/log/openvpn.log

Wat werkt er nu nog niet?

De complete routing tussen het 5 en het 3 segment loopt nog niet correct over de tunnel. Langzaam aan begin ik te vrezen dat dit niet kan, dus als iemand een idee heeft hoe het werkend te krijgen _zonder_ bridging, ben ik hem zeer dankbaar

[BoAC]

Nog niets geprobeerd met iptables to routen op de beide servers?

Dus de pakketten met als doel het andere net doorrouten via de tunnel?

[Zwerver]

BoAC schreef op vrijdag 28 oktober 2005 @ 17:28:
Nog niets geprobeerd met iptables to routen op de beide servers?

Dus de pakketten met als doel het andere net doorrouten via de tunnel?

Nee? Ik zie daar to be honest het nut niet van in?

[BoAC]

Je wilt toch adressen op het andere net bereiken via de tunnel?

[Zwerver]

Ja? Maar dat zou toch met een standaard route moeten werken Of mis ik het doel nu

[TrailBlazer]

bij je server config heb je het al geprobeerd het gw adres bij de route weg te halen. Volgens mij klopt die niet in ieder geval is niet nodig

[Zwerver]

TrailBlazer schreef op vrijdag 28 oktober 2005 @ 19:10:
bij je server config heb je het al geprobeerd het gw adres bij de route weg te halen. Volgens mij klopt die niet in ieder geval is niet nodig

Ik heb zo'n beetje alle routing opties al geprobeerd, en ook zonder dat gateway-adres gaat het helaas niet goed....

[Paul]

Ik heb eenzelfde setup nu net adhv de howto in elkaar gezet? 1 tunnel, en op het netwerk achter de tunnel moet men het netwerk aan de andere kant kunnen bereiken?
Enige probleem dat ik zelf nog heb is dat ik op de gateways zelf wel (het niet-tunnel-ip van) de andere gateway kan pingen, maar verder niet, terwijl ik wel van overal op het net de gateway aan de andere kant kan pingen?

Hoe dan ook, mijn setup:

Netwerk serverside: 10.0/16, server zelf is 10.0.0.253
/etc/openvpn/server.conf:

code:

port 1194
proto udp
dev tun
ca /etc/openvpn/keys/ca.crt
cert /etc/openvpn/keys/server.crt
key /etc/openvpn/keys/server.key  # This file should be kept secret
dh /etc/openvpn/keys/dh1024.pem
server 10.8.0.0 255.255.255.0
ifconfig-pool-persist ipp.txt
push "route 10.0.0.0 255.255.0.0"
client-config-dir ccd
route 10.1.0.0 255.255.0.0
push "dhcp-option DNS 10.0.0.252"
push "dhcp-option WINS 10.0.0.252"
keepalive 10 120
comp-lzo
user nobody
group nogroup
persist-key
persist-tun
status openvpn-status.log
verb 3
mute 5

/etc/openvpn/ccd/client1:

code:

iroute 10.1.0.0 255.255.0.0

Netwerk Clientside 10.1/16, client zelf is 10.1.2.3
/etc/openvpn/client.conf

code:

client
dev tun
proto udp
remote public-ip-van-server 1194 # NAT + firewall op IP
resolv-retry infinite
nobind
user nobody
group nogroup
persist-key
persist-tun
ca /etc/openvpn/keys/ca.crt
cert /etc/openvpn/keys/client1.crt
key /etc/openvpn/keys/client1.key
ns-cert-type server
comp-lzo
verb 3
mute 5

Verder op de pc's in het achterliggende net (tot dusver om te testen pas 1) serverside

code:

route add -net 10.1.0.0 netmask 255.255.0.0 gw 10.0.0.254

en clientside

code:

route add -net 10.0.0.0 netmask 255.255.0.0 gw 10.1.2.3

Tenslotte nog op beide OpenVPN-dozen forwarding enabled:

code:

echo 1 > /proc/sys/net/ipv4/ip_forward

openvpn op beide gateways gestart en ik was klaar.

[Zwerver]

Paul Nieuwkamp schreef op zondag 30 oktober 2005 @ 22:34:
Ik heb eenzelfde setup nu net adhv de howto in elkaar gezet? 1 tunnel, en op het netwerk achter de tunnel moet men het netwerk aan de andere kant kunnen bereiken?
Enige probleem dat ik zelf nog heb is dat ik op de gateways zelf wel (het niet-tunnel-ip van) de andere gateway kan pingen, maar verder niet, terwijl ik wel van overal op het net de gateway aan de andere kant kan pingen?

Als ik lees wat daar staat kan pc1 in segment A nog steeds pc2 in segment B niet pingen? Of lees ik je reply nou gewoon verkeerd?

[Paul]

Jawel, alles en iedereen kan elkaar pingen over beide netten, alleen kunnen tot dusver de gateways geen pc's in het andere net pingen, een pc in dat net kan echter wel die gateway pingen.

Net A -> gw B ok
Net A -> net B ok
Gw A -> gw B ok
Gw A -> net B fout

Net B -> gw A ok
Net B -> net A ok
Gw B -> gw A ok
Gw B -> net A fout

[Zwerver]

Paul Nieuwkamp schreef op maandag 31 oktober 2005 @ 11:37:
Jawel, alles en iedereen kan elkaar pingen over beide netten, alleen kunnen tot dusver de gateways geen pc's in het andere net pingen, een pc in dat net kan echter wel die gateway pingen.

Net A -> gw B ok
Net A -> net B ok
Gw A -> gw B ok
Gw A -> net B fout

Net B -> gw A ok
Net B -> net A ok
Gw B -> gw A ok
Gw B -> net A fout

Dat is dus wel wazig, want mijn setup is exact gelijk aan die van jou (was, vandaag even wat aan het aanpassen enzo) en ik kan vanaf de endpoints wel het ene netwerk inpingen, maar het andere niet en de bakken in de subnets kunnen niks.

[Paul]

Zwerver schreef op maandag 31 oktober 2005 @ 12:05:
ik kan vanaf de endpoints wel het ene netwerk inpingen, maar het andere niet

"het ene netwerk" = dat wat aan eth0 hangt, "het andere" dat aan de andere kant van de tunnel? Ik neem aan dat je wel het andere endpoint kunt pingen? Staat forwarding wel aan op de endpoints? Heb je geen firewall die in de weg zit?

en de bakken in de subnets kunnen niks.

Heb je daar een route ingeklopt? Die push-dingen pushen afaik alleen naar de openvpn-client, niet naat het netwerk daarachter? (\o/ static routes kun je als DHCP-optie ingeven kom ik net achter \o/)

[Zwerver]

[quote]Paul Nieuwkamp schreef op maandag 31 oktober 2005 @ 17:05:
[...]

"het ene netwerk" = dat wat aan eth0 hangt, "het andere" dat aan de andere kant van de tunnel? Ik neem aan dat je wel het andere endpoint kunt pingen? Staat forwarding wel aan op de endpoints? Heb je geen firewall die in de weg zit?

Ja, nee
[...]
Heb je daar een route ingeklopt? Die push-dingen pushen afaik alleen naar de openvpn-client, niet naat het netwerk daarachter? (\o/ static routes kun je als DHCP-optie ingeven kom ik net achter \o/)

Ja Maar ik heb de boel nu maar omgebouwd naar een tap-installatie, dat werkt dus wel. Het blijft echter vaag dat een tun-opbouw gewoon niet werkt

[TrailBlazer]

ik had ook hele nare problemen met tun devices. Gewoon de hele strategie van een tunnel naar een of ander openvpn proces begrijp ik niet.

[pinockio]

Ik ben ook bezig met zoiets, maar dan zonder een tweede gateway. In principe moet een client (bijv. bij mensen thuis, adsl) via de gateway (die in het office-netwerk staat, met IP 10.0.0.210, of openvpn 10.8.0.1) windows-bakken op het office-netwerk (10.0.0.x) kunnen pingen / besturen. Ik kan alleen de gateway pingen op zijn 10.0.0.210 adres.

Is het niet handiger om:

- Óf relevante Windows machines op het office-netwerk óók te laten connecten via OpenVPN met de gateway (via de optie "client-to-client")
- Óf gebruik te maken van een bridget netwerk (Windows XP only voor Windows-clients)

Wat denken jullie ervan? (Ik heb helaas nog geen ervaring met bridged Openvpn netwerken.)

[ Voor 9% gewijzigd door pinockio op 08-11-2005 17:58 ]

[pinockio]

Even een update: het opzetten van een bridged verbinding was een ramp: erg ingewikkeld, en vervolgens maakt de client soms wel contact (na lange tijd) maar meestal krijg ik: TLS handshake failed. Inmiddels ben ik op zoek naar een alternatief, zit nu te denken aan ssh tunneling.

[Verwijderd]

ik heb zo'n setup ook draaien...
2 firewall routers.. met een client server config.
beide machines als firewall staat ik op het tunnel device alles toe.
en met de volgende configs. heb ik volledig verbinding met alle machines.

---

server.conf

---

port 1194
proto udp
dev tun
ca keys/ca.crt
cert keys/server.crt
key keys/server.key
dh keys/dh.pem
server 10.0.1.0 255.255.255.0
ifconfig-pool-persist ipp.txt

push "route 10.0.1.0 255.255.255.0"
push "route 192.168.1.0 255.255.255.0"
client-to-client
client-config-dir client
route 192.168.2.0 255.255.255.0

keepalive 10 120
tls-auth keys/ta.key 0
comp-lzo
user nobody
group nogroup
persist-key
persist-yun

verb 3

---

client

---

iroute 192.168.2.0 255.255.255.0

---

client.conf

---

client
dev tun
proto udp
remote <ip> 1194
resolv-retry infinite
nobind
persist-key
persist-tun
ca keys/ca.crt
cert keys/server.crt
key keys/server.key
ns-cert-type server
tls-remote server
comp-lzo
verb 3

alle machines firewall/routers en achterliggende netwerken kunnen elkaar bereiken zonder gebruik te maken van de tunnel ip range.
Pingen , ip based browsen, ssh, noem het maar op, ook beide firewalls/routers hebben contact op beide ip's hun tunnel ip, maar ook hun interne ip's.

hoop dat jullie hier iets mee kunnen.

[ Voor 27% gewijzigd door Verwijderd op 13-11-2005 19:32 ]

[pinockio]

Dit begrijp ik niet:

client
--------------------------------------------------------------------------------

iroute 192.168.2.0 255.255.255.0

Waar staat dat? In zo'n ccd dir en bestand?

[Paul]

Yup.
Uit de howto:

The next step is to create a file called client2 in the ccd directory. This file should contain the line:

iroute 192.168.4.0 255.255.255.0

This will tell the OpenVPN server that the 192.168.4.0/24 subnet should be routed to client2.

Ik heb momenteel het probleem dat mijn verbinding een hele mooie blokgolf is... 2 minuten up, 2 minuten down, 2 minuten up, 2 minuten down
Ik duik de logfiles maar weer eens in

[DjFoxy]

Hmmm dit klinkt heel erg interessant.
Ik heb al geruime tijd openvpn aan de praat, dwz dat ik van een client naar een router kan komen.
achter die router hangt een netwerk met 192.168.1.0 clients.
Het netwerk waar ik vandaan kom is zit ook in deze range.
Is het dan wel mogelijk omdat ze in beide ranges zitten om de clients achter de router te kunnen benaderen ?
Dit hoeft echter alleen maar via RDC (remote desktop) eigenlijk

[Paul]

Achter de router niet. Als je gaat bridgen weer wel, maar dan moet je zorgen dat je geen dubbele ip-adressen hebt.
Ik heb ervoor gekozen om aan 1 kant het hele ip-plan om te gooien.

Mijn KeepAlive van 120 naar 600 zetten heeft trouwens mijn blokgolf-patroon verholpen, ben nu al sinds14:30 gisteren verbonden zonder ook maar 1 disconnect (die langer dan 15 sec geduurd heeft).

[DjFoxy]

Hallo alweer,

ik ben nu zo ver dat ik een tunnel heb tussen mijn netwerk thuis en het netwerk op kantoor
Thuis = 10.0.0.x kantoor = 192.168.1.x
Ik kan vanaf thuis alle pc's in het netwerk op kantoor pingen.
Ik kan alleen nog steeds niet een Remote desktop verbinding opzetten vanaf thuis naar kantoor.
mijn VPN verbinding geeft mij als ip adres 10.8.0.5 de server aan de andere kant is 10.8.0.1

[Verwijderd]

Je kan beter een nieuw topic openen met een inleidend verhaal over je probleem ipv dit oude topic te schoppen, wat over heel iets anders gaat. Je hebt dan meer kans van slagen.