openvpn bridge Debian

[bleedingeye]

Beste tweakers,

Ik wil mijn openvpn in bridge mode draaien.

Zodra ik via het officieele script van openvpn mijn bridge aanmaak verlies ik echter de connectie met internet. De gateway kan ik ook nog benaderen.


Wel krijg ik openvpn in routing mode draaiende (dus port forwarding en alles klopt) maar dit is niet wat ik wil.

kan iemand mij helpen?

mvg,

bleedingeye

[gertvdijk]

bleedingeye schreef op donderdag 09 juli 2009 @ 15:25:
Ik wil mijn openvpn in bridge mode draaien.

Zodra ik via het officieele script van openvpn mijn bridge aanmaak verlies ik echter de connectie met internet. De gateway kan ik ook nog benaderen.

Wat meer context informatie is wel handig... Wat voor Debian versie, kernel e.d. gebruik je? Wat weet je van ethernet bridges (ebtables)? Definieer 'verliezen van connectie met internet'. Krijg je nog wel een IP? Is de routing tabel nog op orde? Wat is je netwerkconfiguratie? Welk 'officiële' script? Welke versie van OpenVPN? etc. etc.

bleedingeye schreef op donderdag 09 juli 2009 @ 15:25:
kan iemand mij helpen?

Niet zonder wat meer informatie.

[bleedingeye]

Ik heb het gemaakt. na het aanmaken van de bridge was er geen gateway gedefineerd.
maar nu zit ik met een ander probleem. de client (XP) krijgt wel een ip maar kan geen ip adress bereiken aan de server kant. Ik gebruik TAP. ook heeft de client geen default gateway
push "route-gateway (IP) lost dit niet op

[Anoniem: 191133]

Zelf heb ik ook wat gestoeid hiermee maar uiteindelijk heb ik gekozen voor een permanente bridge met STP aan natuurlijk en OpenVPN hier eenmalig een TAP aan te hangen. Ook is het dan handig om de interne OpenVPN bridge functie aan te zetten zodat packets van vpn clients naar vpn clients meteen worden doorgestuurd en niet op de lokale bridge belanden en meteen weer terug worden geroute naar de tap. Je hebt dan eigenlijk 2 bridges.

Maar wat meer info kan inderdaad geen kwaad hoewel mijn glazen bol zegt dat je 'officiele script' gewoon vergeet je fysieke netwerk kaart aan je bridge te knopen en je routing tables verkeerd zet afain je setup verkloot.

[bleedingeye]

SERVER:

ifconfig voor het aanmaken van de bridge

eth0 Link encap:Ethernet HWaddr 00:0f:66:7f:39:89
inet addr:192.168.2.100 Bcast:192.168.2.255 Mask:255.255.255.0
inet6 addr: fe80::20f:66ff:fe7f:3989/64 Scope:Link
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:82 errors:0 dropped:0 overruns:0 frame:0
TX packets:49 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:100
RX bytes:6426 (6.2 KiB) TX bytes:6861 (6.7 KiB)

lo Link encap:Local Loopback
inet addr:127.0.0.1 Mask:255.0.0.0
inet6 addr: ::1/128 Scope:Host
UP LOOPBACK RUNNING MTU:16436 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:0
RX bytes:0 (0.0 TX bytes:0 (0.0

---

Ifconfig NA het aanmaken van de bridge

br0 Link encap:Ethernet HWaddr 00:0f:66:7f:39:89
inet addr:192.168.2.100 Bcast:192.168.2.255 Mask:255.255.255.0
inet6 addr: fe80::20f:66ff:fe7f:3989/64 Scope:Link
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:22 errors:0 dropped:0 overruns:0 frame:0
TX packets:28 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0
RX bytes:1494 (1.4 KiB) TX bytes:2160 (2.1 KiB)

eth0 Link encap:Ethernet HWaddr 00:0f:66:7f:39:89
inet6 addr: fe80::20f:66ff:fe7f:3989/64 Scope:Link
UP BROADCAST RUNNING PROMISC MULTICAST MTU:1500 Metric:1
RX packets:206 errors:0 dropped:0 overruns:0 frame:0
TX packets:116 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:100
RX bytes:13924 (13.5 KiB) TX bytes:15275 (14.9 KiB)

lo Link encap:Local Loopback
inet addr:127.0.0.1 Mask:255.0.0.0
inet6 addr: ::1/128 Scope:Host
UP LOOPBACK RUNNING MTU:16436 Metric:1
RX packets:4 errors:0 dropped:0 overruns:0 frame:0
TX packets:4 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0
RX bytes:480 (480.0 TX bytes:480 (480.0

tap0 Link encap:Ethernet HWaddr 00:ff:98:a9:4c:7d
inet6 addr: fe80::2ff:98ff:fea9:4c7d/64 Scope:Link
UP BROADCAST RUNNING PROMISC MULTICAST MTU:1500 Metric:1
RX packets:0 errors:0 dropped:0 overruns:0 frame:0
TX packets:0 errors:0 dropped:13 overruns:0 carrier:0
collisions:0 txqueuelen:100
RX bytes:0 (0.0 TX bytes:0 (0.0

---

Bridgestart script

#!/bin/bash

#################################
# Set up Ethernet bridge on Linux
# Requires: bridge-utils
#################################

# Define Bridge Interface
br="br0"

# Define list of TAP interfaces to be bridged,
# for example tap="tap0 tap1 tap2".
tap="tap0"

# Define physical ethernet interface to be bridged
# with TAP interface(s) above.
eth="eth0"
eth_ip="192.168.2.100"
eth_netmask="255.255.255.0"
eth_broadcast="192.168.2.255"

for t in $tap; do
openvpn --mktun --dev $t
done

brctl addbr $br
brctl addif $br $eth

for t in $tap; do
brctl addif $br $t
done

for t in $tap; do
ifconfig $t 0.0.0.0 promisc up
done

ifconfig $eth 0.0.0.0 promisc up

ifconfig $br $eth_ip netmask $eth_netmask broadcast $eth_broadcast

route add default gw 192.168.2.254

---

Server config

local 192.168.2.100
port 1194
proto tcp
dev tap
ca /etc/openvpn/easy-rsa/2.0/keys/ca.crt
cert /etc/openvpn/easy-rsa/2.0/keys/server.crt
key /etc/openvpn/easy-rsa/2.0/keys/server.key # This file should be kept secret
dh /etc/openvpn/easy-rsa/2.0/keys/dh1024.pem
ifconfig-pool-persist ipp.txt
server-bridge 192.168.2.100 255.255.255.0 192.168.2.150 192.168.2.160
push "route 192.168.2.0 255.255.255.0"
client-config-dir /etc/openvpn/ccd
route 192.168.1.0 255.255.255.0
keepalive 10 120
comp-lzo
persist-key
persist-tun
status openvpn-status.log
verb 3

---

Client config

client
dev tap
dev-node openvpn
proto tcp
remote X.X.X.X 1194
resolv-retry infinite
nobind
persist-key
persist-tun
ca "C:\\Program Files (x86)\\OpenVPN\\config\\ca.crt"
cert "C:\\Program Files (x86)\\OpenVPN\\config\\client1.crt"
key "C:\\Program Files (x86)\\OpenVPN\\config\\client1.key"
comp-lzo
verb 3
pull

[Pim.]

Bleedingeye, om te beginnen, welkom op GoT !

Maar net als in je TS mis ik nu eigenlijk weer de info over dingen als

• wat heb je er aan gedaan om het op te lossen
• welke tutorials heb je gevolgd
• welke zoektermen heb je gebruikt op het forum en op bing/google

Het vermelden van dit soort dingen maakt het voor anderen een stuk makkelijker om je te helpen omdat ze dan zien dat je er zelf ook iets aan doet. Ook voorkomt het dubbel werk

Een config neergooien en hopen dat iemand het voor je op gaat lossen is echt niet voldoende

[ Voor 3% gewijzigd door Pim. op 11-07-2009 11:31 ]

[bleedingeye]

ik heb de howto op de officiele site gevolgd http://openvpn.net/index..../documentation/howto.html
hierna heb ik ook andere tutorials op google gezocht maar deze losten mijn probleem niet op
ben al een paar dagen aan het googlen op termen zoals "openvpn client gateway" "open vpn client push gateway" enz.
maar ik heb te weinig kennis van netwerken om het probleem op te lossen.
wat zou de gateway van de client moeten zijn? ip dat de openvpn NIC krijgt?

[Anoniem: 191133]

Je haalt een aantal dingen door de war.

Zie je OpenVPN server als een virtuele netwerk switch en je vpn verbindingen als een hele lange netwerk kabel. De Bridge op je OpenVPN server is ook een virtuele switch. Je hebt met OpenVPN eigenlijk een hele lange netwerk kabel naar de vpn client gelegt. dus eigenlijk zo:

Internet <> Jouw router <> Lokale bridge <> VPN Bridge <> VPN client <> Externe netwerk <> Internet.

Dus tenzij je al het internet van je vpn client over JOUW router wilt sturen moet je juist geen gateway pushen.

Ik denk dat het makkelijkste setup voor jouw is om helemaal geen lokale bridge te gebruiken en enkel de interne OpenVPN bridge te gebruiken. dus eigenlijk zo:

OpenVPN Client <> OpenVPN Bridge <> OpenVPN Client

Als je op je VPN een andere IP range gebruikt zal Linux/Windows alle traffic voor je andere VPN clients automatische over je VPN TAP sturen. Je Internet gaat gewoon over je standaard netwerkkaart. Enig nadeel is dat je dus alleen VPN traffic hebt tussen clients onderling. Alsof iedereen een hele lange netwerkkabel uit zijn raam heeft gegooit een allemaal in dezelfde switch gestoken.

Maar goed opnieuw: vertel eens iets beter wat je precies wilt en wat je al hebt gedaan. Je config hier neerdumpen helpt niet echt. Dus lees de quickstart en forum regels goed. Vertel verder eens:

• Welk OS/distro gebruik je en welke versie
• Welke versie van OpenVPN server en client
• Zijn de client machines Windows of anders? Linux? FreeBSD? etc.
• Welk doel heb je? Wil je slechts wat computers met elkaar verbinden of hele netwerken?
• Welke programma's moeten werken over VPN? Welke protocollen?
• Zijn de clients vaste thuis computers die altijd via dezelde ADSL/Cable verbinden? of mobiele laptops?
• Wat zijn de specs van je server en hoe veilig wil je de connecties hebben?

Als je deze vragen eens begint in te vullen dan kunnen wij je veel gerichter helpen.

[bleedingeye]

Als Distro gebruik ik Debian 5.0.2 met kernel 2.6.26-2

versie openvpn server 2.1~rc11-1

versie openvpn client 2.0.9 met gui

de client machines zijn windows. ( xp/vista/windows 7 hebben allemaal het zelfde probleem)

als doel heb ik dat ik verbinding kan maken met mijn netwerken vanaf andere locaties en daar mijn servers/ werkstations kan benaderen (samba/ print/ ssh/ scp/ enz). werkstations in het zelfde netwerk als de server hoeven geen verbinding met clients te maken. en ook hoeven de clients onderling geen verbinding met elkaar te hebben.

de clients hebben altijd de zelfde vaste verbinding.

de openpvn server draait nog virtueel (virtualbox) maar ik heb het ook dedicated geprobeerd maar dit maakt geen verschil.

[Anoniem: 191133]

Kijk dat is al een stuk duidelijker.

Je wilt dus een stel externe windows computers laten verbinden met je lokale servers. Dat is eigenlijk wel een best complexe setup omdat je zowel je lokale als je externe computers in het zelfde netwerk hebt.

Allereerst moet je een permanente bridge hebben. Deze defineer je in /etc/networking/interfaces als volgt:

code:

# Voorbeeld van een simpele permanente bridge setup in Debian 5
#

# Interfaces die bij het opstarten actief moeten worden
auto lo eth0 br0

# de loopback interface
iface lo inet loopback
 up /sbin/iptables-restore < /etc/iptables.up.rules
 up /sbin/ip6tables-restore < /etc/ip6tables.up.rules

# de fysieke netwerkkaart
iface eth0 inet manual
 up /sbin/iptables-restore < /etc/iptables.up.rules
 up /sbin/ip6tables-restore < /etc/ip6tables.up.rules

# de permanente bridge
iface br0 inet dhcp
 bridge_ports eth0
 bridge_wait 32
 bridge_hello 2
 bridge_fd 9
 bridge_maxage 12
 bridge_stp on
 up /sbin/ifconfig eth0 0.0.0.0 promisc up
 up /sbin/iptables-restore < /etc/iptables.up.rules
 up /sbin/ip6tables-restore < /etc/ip6tables.up.rules

Herstart je server of roep /etc/init.d/networking restart en check met ifconfig het resultaat. Met brctl show zou je nu moeten zien dat je een bridge br0 hebt met 1 port: eth0 en STP aan. STP is om een loop te voorkomen.

Ik heb even aangenomen dat je dhcp gebruikt aangezien dat wel zo makkelijk is om semi-statische IPs uit te delen. Vergeet ook niet je firewall setup script aan te roepen. Zelf gebruik ik iptables-restore zoals je kunt zien. Wat deze setup eigenlijk doet is eth0 niet opzetten en een bridge aan te maken en dan met de up stanza eth0 naar 0.0.0.0 initializeren en in promiscus modus te zetten. Volgende stap is OpenVPN hier aan knopen.

Ik heb hier zelf geen OpenVPN netwerk waarop ik kan testen maar zoiets zou je server config kunnen zijn:

code:

# TAP device settings
dev tap
dev-type tap

# We draaien in TLS server modus over UDP.
server-bridge
mode server
tls-server
proto udp
port 1194

# Log en status settings
verb 4
status openvpn-status.log
log-append /var/log/openvpn.log

# De PKI settings die we gebruiken
ca /etc/openvpn/easy-rsa/2.0/keys/ca.crt
cert /etc/openvpn/easy-rsa/2.0/keys/server.crt
key /etc/openvpn/easy-rsa/2.0/keys/server.key
dh /etc/openvpn/easy-rsa/2.0/keys/dh1024.pem
tls-timeout 2
reneg-sec 3600

# Draai met beperkte rechten nadat we de tap hebben opgezet
up sh -c "/sbin/brctl addif br0 $1"
user nobody
group nobody

# Stel een aantal limieten in om overbelasting/(d)dos te voorkomen
connect-freq 5
max-clients 25
max-routes-per-client 256
bcast-buffers 256

# Hou de verbinding(en) in leven door firewalls en herstarts heen.
keepalive 5 30
persist-tun
persist-key
ifconfig-pool-persist ipp.txt

# Client connect settings
client-config-dir /etc/openvpn/ccd
comp-lzo no
opt-verify

Opnieuwe ga ik er even vanuit dat je al een DHCP server op je netwerk hebt die IPs uitdeelt. Deze config is een beetje advanced omdat er geen vaste IPs in zitten en de server met beperkte read-only rechten draait wat wel zo veilig is. Ook ben ik overgestapt op UDP, was er een reden dat je TCP gebruikte?

Ook moet je mischien een logrotate rule aanmaken voor de logfile in /var/log/openvpn.log zodat die niet volraakt.

En als client config zou je zoiets kunnen doen:

code:

# We zijn client en werken met een TAP device over UDP
client
proto udp
dev tap
dev-type tap

# En we verbinden met 
remote x.x.x.x 1194 # Vul hier bijvoorbeeld het externe zichtbare IP van je router in als je port-forwarding doet.
explicit-exit-notify 1
resolv-retry infinite
nobind
float

# PKI bestanden en settings die we gebruiken. Let op! relative paden.
ca "ca.crt"
dh "dh2048.pem"
cert "client1.crt"
key "client1.key"
tls-auth ta.key 1

# Loggin settings
verb 4
log-append "client1.log"

# Verbinding settings.
keepalive 5 30 # deze setting kan het beste gelijk zijn aan die op je server.
comp-lzo no
persist-key
persist-tun

Wat deze setup eigenlijk doet is puur een lange virtuele netwerkkabel zijn. Er worden dan ook geen IPs uitgedeeld of gateways doorgegeven. Dat is de taak van je DHCP server nu. Let wel op wie je dus een key geeft. Groot nadeel is dat mogelijk nu al het internet verkeer van die clients ook over de VPN gaat.

Ook gaat dit waarschijnlijk niet werken als de fysieke netwerkkaart op de client in dezelfde IP range zit van 192.168.2.x omdat windows de 2 netwerken niet uit elkaar kan houden.

Ik heb deze setup niet getest en waarschijnlijk moet je het nog wel wat tweaken maar dit heb ik bij elkaar gepuzzeld via de zeer goede handleiding op http://www.openvpn.net/in...anuals/69-openvpn-21.html

Ook kun je beter de beta (2.1rc18) client gaan draaien ivm features en dat dan zowel server als client versie 2.1x draaien naast dat de huidige stable ook al 3 jaar oud is immidels. Ook ondersteunt de beta al 64bit windows.