Openvpn server opzetten

[Gijs007]

Beste tweakers,

Dit is een vervolg op dit topic: https://gathering.tweakers.net/forum/list_messages/1591002

Ik ben bezig met het opzetten van een openvpn server op een VPS om mijn verkeer langs die server te sturen.
De VPS draait op Ubuntu server 14.04 en openvpn is geïnstalleerd.

De VPN heeft 4 IP adressen waar ik gebruik van kan maken. (23.246.204.10 - 23.246.204.14)
De cliënt maakt verbinding op IP 23.246.204.10 en krijgt IP 23.246.204.14 toegewezen.

Mijn server config ziet er als volgt uit:

code:

port 1194
proto udp
dev tun
ca ca.crt
cert server.crt
key server.key  # This file should be kept secret
dh dh2048.pem
server 23.246.204.8 255.255.255.248
ifconfig-pool-persist ipp.txt
keepalive 10 120
persist-key
persist-tun
status openvpn-status.log
verb 3

Wat mij nu opvalt is dat ik geen verkeer door de tunnel kan sturen, als ik bijvoorbeeld de client probeer te pingen via: 23.246.204.14 dan ping ik de VPS en niet de client..

Hoe kan ik dit oplossen? knip, geen werving

[ Voor 10% gewijzigd door Equator op 10-06-2014 07:26 ]

[J0HAN]

"De cliënt maakt verbinding op IP 23.246.204.10 en krijgt IP 23.246.204.14 toegewezen."

Waarom krijgt je client een WAN adres toegewezen?

[supayoshi]

hij snapt het niet helemaal, dat je geen 4 ip adressen nodig hebt >_<

[johnkeates]

Regel NAT, zet forwarding aan, geef de tunnel en het NAT adres losse subnets (bijv. 10.0.99.0/24 als tunnel network en 10.0.12.0/24 als NAT netwerk), forward alles lekker of gebruik iptables. Zet DHCP en DNS op als je dat leuk vind.

[Gijs007]

@johnkeates
NAT is niet mogelijk, in ieder geval niet in de traditionele zin via een router.
De client en openvpn server zitten beiden direct aan de WAN interface.

J0HAN schreef op maandag 09 juni 2014 @ 13:36:
"De cliënt maakt verbinding op IP 23.246.204.10 en krijgt IP 23.246.204.14 toegewezen."

Waarom krijgt je client een WAN adres toegewezen?

Omdat de VPN zijn verkeer over het internet moet versturen en niet in een lokaal subnet.
Daarnaast vinden veel applicaties het fijn om hun eigen WAN adres te weten en niet een intern adres dat met NAT wordt omgezet.

Het is de bedoeling dat client verbind via internet naar de openvpn server en van daar naar het internet, als een soort proxy.

[ Voor 24% gewijzigd door Gijs007 op 09-06-2014 14:10 ]

[J0HAN]

Gijs007 schreef op maandag 09 juni 2014 @ 14:07:
@johnkeates
NAT is niet mogelijk, in ieder geval niet in de traditionele zin via een router.
De client en openvpn server zitten beiden direct aan de WAN interface.


[...]

Omdat de VPN zijn verkeer over het internet moet versturen en niet in een lokaal subnet.
Daarnaast vinden veel applicaties het fijn om hun eigen WAN adres te weten en niet een intern adres dat met NAT wordt omgezet.

Het is de bedoeling dat client verbind via internet naar de openvpn server en van daar naar het internet, als een soort proxy.

Geen idee waarom je client daarvoor een WAN adres zou moeten krijgen

Wat jij beschrijft kan prima via NAT. Je client krijgt een intern IP en via NAT gaat je verkeer het internet op.
Ik heb ongeveer hetzelfde gedaan via DD-WRT op mijn NETGEAR router.
(ook als proxy om via een open internet verbinding toch veilig gebruikt te kunnen maken van het internet)

[Gijs007]

J0HAN schreef op maandag 09 juni 2014 @ 14:16:
[...]


Geen idee waarom je client daarvoor een WAN adres zou moeten krijgen

Wat jij beschrijft kan prima via NAT. Je client krijgt een intern IP en via NAT gaat je verkeer het internet op.
Ik heb ongeveer hetzelfde gedaan via DD-WRT op mijn NETGEAR router.
(ook als proxy om via een open internet verbinding toch veilig gebruikt te kunnen maken van het internet)

Maar hoe kan ik de PC achter de tunnel dan pingen als die geen publiek IP adres heeft?

[_root]

Volgens mij mis je ook nog een routering....

push "redirect-gateway def1"
push "dhcp-option DNS 8.8.8.8"

Gebruik voor je client een private adres, zet ip forward aan, nat al het verkeer achter je publieke adres..

Private adres
server 192.168.99.0 255.255.255.0

NAT:
uiteraard eth0 vervangen door je eigen WAN interface

iptables -t nat -A POSTROUTING -s 192.168.99.0/24 -o eth0 -j MASQUERADE

ip-forward:
echo 1 >/proc/sys/net/ipv4/ip_forward

[ Voor 107% gewijzigd door _root op 09-06-2014 15:45 ]

[J0HAN]

Gijs007 schreef op maandag 09 juni 2014 @ 14:18:
[...]

Maar hoe kan ik de PC achter de tunnel dan pingen als die geen publiek IP adres heeft?

Dat gaat wat lastig worden, maar waarom zou je (vanaf het internet?) je PC achter een VPN willen pingen??

[johnkeates]

Uh, ik heb 7 losse OpenVPN servers op verschillende locaties (3x DC, 2x Kabel, 1x VDSL, 1x ADSL2) op verschillende configuraties draaien, maar dus wel allemaal met NAT. Werkt prima.

Je verbinding ziet er uiteindelijk zo uit:

code:

[ Client ][ Lokaal IP ][ NAT ][ WAN IP ] ----- [ WAN IP] [ Server ]

Je tunnel zo:

code:

[ Client ][ Tunnel IP ][ Lokaal IP ][ NAT ][ WAN IP] ----- [ WAN IP ][ TAP/TUN ][ Tunnel IP ][ Server ]

En je VPN verbinding zo:

code:

[ Client ][ VPN Client IP][ Tunnel IP ][ Lokaal IP ][ NAT ][ WAN IP] ----- [ WAN IP ][ TAP/TUN ][ Tunnel IP ][ Server ][ NAT ][ WAN IP ]

Zelfs nog met NAT tussen je Server WAN IP en OpenVPN server werkt het prima! Dat is juist het briljante van OpenVPN.

Als je client verbinding up is krijg je zo'n if erbij:

code:

tun0: flags=8851<UP,POINTOPOINT,RUNNING,SIMPLEX,MULTICAST> mtu 1500
    inet 10.10.8.10 --> 10.10.8.9 netmask 0xffffffff 
    open (pid 57135)

Heeft dus niks met WAN IP's op je VPN te maken.

[ Voor 26% gewijzigd door johnkeates op 09-06-2014 14:52 ]

[Gijs007]

_root schreef op maandag 09 juni 2014 @ 14:20:
Volgens mij mis je ook nog een routering....

push "redirect-gateway def1"
push "dhcp-option DNS 8.8.8.8"

Gebruik voor je client een private adres, zet ip forward aan, nat al het verkeer achter je publieke adres..

Private adres
server 192.168.99.0 255.255.255.0

NAT:
uiteraard eth0 vervangen door je eigen WAN interface

iptables -t nat -A POSTROUTING -s 10.99.99.0/24 -o eth0 -j MASQUERADE

ip-forward:
echo 1 >/proc/sys/net/ipv4/ip_forward

Thanks, er komt nu verkeer doorheen.
Ik moest wel: het ip aanpassen in: 10.99.99.0/24

Het enige probleem wat ik nu nog heb is dat ik dus geen verkeer van af de andere kant kan opzetten.
Ik wil dus een wan IP aan de VPN toekennen zodat ik deze kan pingen en bereiken via de tunnel. (voor bijvoorbeeld remote desktop)

[_root]

Gijs007 schreef op maandag 09 juni 2014 @ 15:31:
[...]

Thanks, er komt nu verkeer doorheen.
Ik moest wel: het ip aanpassen in: 10.99.99.0/24

Het enige probleem wat ik nu nog heb is dat ik dus geen verkeer van af de andere kant kan opzetten.
Ik wil dus een wan IP aan de VPN toekennen zodat ik deze kan pingen en bereiken via de tunnel. (voor bijvoorbeeld remote desktop)

Oeps..... tikfoutje, je heb gelijk..... zowel de adressen in de NAT als in de serverconfig moeten overeen komen. (aangepast)

Je kan het RDP probleem op 2 manieren oplossen:

1 : Beide verbinden naar de openVPN server, en dan het private ip adres gebruiken om de machine over te nemen. Absoluut de beste oplossing !!!

2: op het externe ip adres een PAT/NAT maken op poort 3389 naar het openvpn adres van de client....

[ Voor 6% gewijzigd door _root op 09-06-2014 15:45 ]

[Gijs007]

Remote desktop was maar een voorbeeld, er draait ook andere server software op de client die extern benaderbaar moet zijn.
Zie ook mijn vorige topic: https://gathering.tweakers.net/forum/list_messages/1591002

Dus punt 2 lijkt mij de beste oplossing, is dit ook mogelijk voor al het verkeer?

Daarnaast is het mogelijk om de client het zelfde adres toe te kennen als het externe adres? (dit omdat de eerder genoemde server software het niet leuk vind als er NAT plaatsvind waarbij het een ander IP krijgt.)

[ Voor 9% gewijzigd door Gijs007 op 09-06-2014 15:47 ]

[_root]

Gijs007 schreef op maandag 09 juni 2014 @ 15:43:
Remote desktop was maar een voorbeeld, er draait ook andere server software op de client die extern benaderbaar moet zijn.
Zie ook mijn vorige topic: https://gathering.tweakers.net/forum/list_messages/1591002

Dus punt 2 lijkt mij de beste oplossing, is dit ook mogelijk voor al het verkeer?

Daarnaast is het mogelijk om de client het zelfde adres toe te kennen als het externe adres? (dit omdat de eerder genoemde server software het niet leuk vind als er NAT plaatsvind waarbij het een ander IP krijgt.)

Ja het kan, maar er zijn veel manieren om tot een oplossing te komen.
Als je veel ervaring hebt met openvpn en linux zou ik misschien een bridge configuratie op een interface aanraden, maar is wel een draak om aan de gang te krijgen.

Maar de eenvoudig oplossing is dan om toch een PAT/NAT te doen naar binnen toe.
Als je zelf wat te weinig ervaring hebt met iptables zou je eens kunnen kijken naar webmin (www.webmin.com).

Hier kan je vrij eenvoudig je poorten open zetten naar binnen toe....

[Gijs007]

Helaas ben ik nieuw met openvpn en linux.

Ik ben wel de volgende tutorial tegen gekomen:
http://openvpn.net/index....76-ethernet-bridging.html

Alleen weet ik niet of dat deze doet wat ik wil.
Als ik het goed begrijp dan maak ik een bridge in Linux tussen de tunnel en eth1(WAN)

Daarna pas ik de config van openvpn aan:
server-bridge server 23.246.204.8 255.255.255.248 server 23.246.204.11 23.246.204.14
Klopt dit?

Maar dan draait de VPN als nog niet op het zelfde IP als WAN.

[ Voor 6% gewijzigd door Gijs007 op 09-06-2014 17:12 ]

[_root]

Wat je eigenlijk doet is het aanmaken van een virtuele interface, vaak wordt de naam br0 aangehouden voor deze interface. Een bridge interface is een eigenlijk een container die verschillende interfaces kan bundelen.
Het externe ip adres komt op deze br0 interface. daarna koppel je de andere interfaces aan deze br0 interface.

Maar om dat op een VPS te doen zonder fysieke toegang of een console is eigenlijk onbegonnen werk.
Op het moment dat je met een br0 interface gaat spelen verlies je gelijk de remote verbindingen en is de server onbereikbaar.

Heb je nog verder gekeken naar het naar binnen doorzetten van poorten?
Dat principe is namelijke veel eenvoudiger en je blijft aan beide zijde je verbindingen behouden en je server is te bereiken via het externe IP adres

[ Voor 3% gewijzigd door _root op 09-06-2014 17:37 ]

[Gijs007]

als ik een br0 interface maak vallen dan al mijn interfaces weg?

Ik heb namelijk eth0 (is een interface die ik alleen via servers binnen het datacentrum of vpn van het datacentrum kan benaderen)

eth1 is de WAN interface
eth1:0 t/m eth1:3 zijn de extra IP's voor eth1.

Dus als ik die bridge aan eth1:0 koppel dan vallen die andere interfaces toch niet weg?

[_root]

Alles met een : zijn virtuele interfaces op een bestaande interface, en aangezien dat dit dus geen echte interfaces zijn durf ik hier geen uitspraak over of je dit mag bridgen, nooit gedaan, ik weet dat er beperkingen zitten aan aan virtuele interface, proberen maar zou ik zeggen...
Tenminste als je er op een andere manier nog bij kan komen !

[johnkeates]

Je kan beter eth1 op een bridge pluggen, de bridge het orginele eth1 adres geven en dan dummy interfaces maken met de resterende IP's en die aan de bridge hangen.

Daarnaast heb je als je op je OpenVPN server clients met elkaar wil laten praten wel een configuratie item wat je aan moet zetten. Standaard kunnen clients niet met elkaar communiceren!

[ Voor 36% gewijzigd door johnkeates op 09-06-2014 18:16 ]

[Gijs007]

johnkeates schreef op maandag 09 juni 2014 @ 18:15:
Je kan beter eth1 op een bridge pluggen, de bridge het orginele eth1 adres geven en dan dummy interfaces maken met de resterende IP's en die aan de bridge hangen.

Waarom is dat beter?
Btw:Mijn clients hoeven niet met elkaar te praten.

Ik zit alleen vast op dat bridge start script:
http://openvpn.net/index....76-ethernet-bridging.html

Heb het bestand bridge-start opgeslagen in /etc/openvpn/
Maar als ik het probeer uit te voeren krijg ik: de melding command not found

Mijn 2de vraag is hoe ik er voor zorg dat de bridge ook gaat werken bij het opstarten van Linux.

Als ik de server niet meer kan bereiken geef ik hem gewoon een restart, dan is die bridge er ook niet meer.
Uiteindelijk is het wel de bedoeling(als alles correct werkt) dat die bij het opstarten geïnitialiseerd wordt.

Desnoods herinstalleer ik de VPS, er staat behalve openvpn verder niks op

[ Voor 15% gewijzigd door Gijs007 op 09-06-2014 18:38 ]

[_root]

Gijs007 schreef op maandag 09 juni 2014 @ 18:20:
[...]

Heb het bestand bridge-start opgeslagen in /etc/openvpn/
Maar als ik het probeer uit te voeren krijg ik: de melding command not found

Je moet het bestand nog uitvoerbaar maken:
chmod +x /etc/openvpn/<bestandsnaam>

uitvoeren in de openvpn directory ./<bestandsnaam> of /etc/openvpn/<bestandsnaam>


Stop dit gewoon eens in je server:

iptables -t nat -A PREROUTING -p tcp -m tcp -i eth1:0 --dport 80 -j DNAT --to-destination 10.99.99.6:80
Heb je verbinding op poort 80 !!!

Ik heb het naar een externe website even opgezet:

http://www.vdwolf.nl:81/

even op luisterend op poort 81, 80 in gebruik

[ Voor 69% gewijzigd door _root op 09-06-2014 20:33 ]

[Gijs007]

zo als ik al eerder zij gaat NAT niet goed werken met de apps die ik gebruik, heb dat al vaker gemerkt met portforwarding. (het interne IP wordt dan doorgestuurd naar de clients en dat werkt dan niet goed)

Ik kan bij de VPS via een 2de netwerk interface, dus ook als ik met de WAN interface aan het spelen ben kan ik er nog bij.

Ik heb inmiddels het script handmatig uitgevoerd:

code:

openvpn --mktun --dev tap0
brctl addbr br0
ip link set dev br0 up
brctl addif br0 eth1:0
ip link set dev br0 up
brctl addif br0 tap0
ip link set dev br0 up
ifconfig tap0 0.0.0.0 promisc up
ifconfig eth1:0 0.0.0.0 promisc up
ifconfig br0 23.246.204.11 255.255.255.248 broadcast 23.246.204.15

Maar bij: brctl addif br0 krijg ik de foutmelding: dev is duplicate or tap0 is garbage
Hoe los ik dit op?

[_root]

Staat tap0 al in de bridge? : brctl show

[Gijs007]

Heb net de server gereboot en de ip link set dev br0 up overgeslagen.
Nu werkt het wel.

ifconfig eth1:0 0.0.0.0 promisc up werkte niet
heb toen het ip vervangen met het IP die die interface eerst had en dat werkt wel.

Probleem blijft echter dat ik eth1 zelf niet meer kan bereiken, hoe breng ik die weer online?

[_root]

ifup eth1, anders post eens een ifconfig output

[Gijs007]

code:

br0       Link encap:Ethernet  HWaddr 06:5b:64:42:82:e4
          inet addr:23.246.204.11  Bcast:23.246.204.15  Mask:255.255.255.248
          inet6 addr: fe80::45b:64ff:fe42:82e4/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:176 errors:0 dropped:0 overruns:0 frame:0
          TX packets:8 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0
          RX bytes:9704 (9.7 KB)  TX bytes:672 (672.0 B)

eth0      Link encap:Ethernet  HWaddr 06:db:dd:96:a7:58
          inet addr:10.107.86.130  Bcast:10.107.86.191  Mask:255.255.255.192
          inet6 addr: fe80::4db:ddff:fe96:a758/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:1186 errors:0 dropped:0 overruns:0 frame:0
          TX packets:819 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:93081 (93.0 KB)  TX bytes:137996 (137.9 KB)

eth1      Link encap:Ethernet  HWaddr 06:5b:64:42:82:e4
          inet addr:23.246.204.10  Bcast:23.246.204.15  Mask:255.255.255.248
          inet6 addr: fe80::45b:64ff:fe42:82e4/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:5526 errors:0 dropped:0 overruns:0 frame:0
          TX packets:499 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:1284293 (1.2 MB)  TX bytes:56574 (56.5 KB)

eth1:0    Link encap:Ethernet  HWaddr 06:5b:64:42:82:e4
          inet addr:23.246.204.11  Bcast:23.255.255.255  Mask:255.0.0.0
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1

eth1:1    Link encap:Ethernet  HWaddr 06:5b:64:42:82:e4
          inet addr:23.246.204.12  Bcast:23.246.204.15  Mask:255.255.255.248
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1

eth1:2    Link encap:Ethernet  HWaddr 06:5b:64:42:82:e4
          inet addr:23.246.204.13  Bcast:23.246.204.15  Mask:255.255.255.248
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1

eth1:3    Link encap:Ethernet  HWaddr 06:5b:64:42:82:e4
          inet addr:23.246.204.14  Bcast:23.246.204.15  Mask:255.255.255.248
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1

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:65536  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 B)  TX bytes:0 (0.0 B)

tap0      Link encap:Ethernet  HWaddr c2:94:0f:85:8f:12
          inet addr:23.246.204.11  Bcast:23.255.255.255  Mask:255.0.0.0
          UP BROADCAST PROMISC 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)

root@dal1:~#

Heb ifup eth1 geprobeerd, maar die zegt eth1 already configured.

_root schreef op maandag 09 juni 2014 @ 21:06:
Staat tap0 al in de bridge? : brctl show

Wat mij opvalt is dat er staat interfaces eth1 en tap0
Zoe dit niet eth1:0 moeten zijn?

[ Voor 3% gewijzigd door Gijs007 op 09-06-2014 21:46 ]

[_root]

Ik kom al 3x de 23.246.204.11 tegen en 2 met een mask van 255.0.0.0, dus momenteel een grote bende op netwerk gebied...
Dus dat zal de oorzaak zijn dat die niet bereikbaar is.
Ook de onderdelen van de bridge hebben nog ip adressen.
Volgens mij gaat het ook niet werken met virtuele interfaces.
Ik zou proberen de br0 met het externe ip op te brengen en de hele eth1 in de bridge te zetten.
ifconfig eth1 0.0.0.0

brctl addif br0 eth1
brctl addif br0 tap1

[ Voor 7% gewijzigd door _root op 09-06-2014 22:36 ]

[Gijs007]

_root schreef op maandag 09 juni 2014 @ 21:59:
Ik kom al 3x de 23.246.204.11 tegen en 2 met een mask van 255.0.0.0, dus momenteel een grote bende op netwerk gebied...
Dus dat zal de oorzaak zijn dat die niet bereikbaar is.
Ook de onderdelen van de bridge hebben nog ip adressen.
Volgens mij gaat het ook niet werken met virtuele interfaces.
Ik zou proberen de br0 met het externe ip op te brengen en de hele eth1 in de bridge te zetten.
ifconfig eth1 0.0.0.0

brctl addif br0 eth0
brctl addif br0 tap1

edit:

verbinding op de .11

Ik denk dat je tap0 en eth1 bedoelt

Als ik: ifconfig eth1 0.0.0.0 uitvoer dan heeft eth1 alleen nog een Ipv6 adres. en alle eth1:0 t/m eth1:3 zijn dan weg.

Daarna: ifconfig br0 23.246.204.11 netmask 255.255.255.248 broadcast 23.246.204.15
Uitgevoerd, maar nog steeds kan ik de server niet bereiken op de WAN ip's dus ik kan ook de VPN client niet laten verbinden.

code:

br0       Link encap:Ethernet  HWaddr 06:5b:64:42:82:e4
          inet addr:23.246.204.11  Bcast:23.246.204.15  Mask:255.255.255.248
          inet6 addr: fe80::45b:64ff:fe42:82e4/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:23 errors:0 dropped:0 overruns:0 frame:0
          TX packets:8 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0
          RX bytes:1406 (1.4 KB)  TX bytes:672 (672.0 B)

eth0      Link encap:Ethernet  HWaddr 06:db:dd:96:a7:58
          inet addr:10.107.86.130  Bcast:10.107.86.191  Mask:255.255.255.192
          inet6 addr: fe80::4db:ddff:fe96:a758/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:454 errors:0 dropped:0 overruns:0 frame:0
          TX packets:378 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:37904 (37.9 KB)  TX bytes:70708 (70.7 KB)

eth1      Link encap:Ethernet  HWaddr 06:5b:64:42:82:e4
          inet6 addr: fe80::45b:64ff:fe42:82e4/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:461 errors:0 dropped:0 overruns:0 frame:0
          TX packets:506 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:57047 (57.0 KB)  TX bytes:72472 (72.4 KB)

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:65536  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 B)  TX bytes:0 (0.0 B)


root@dal1:~# brctl show
bridge name     bridge id               STP enabled     interfaces
br0             8000.065b644282e4       no              eth1
                                                        tap0

[ Voor 50% gewijzigd door Gijs007 op 09-06-2014 22:43 ]

[_root]

staan de routes nog goed ?
route -n ?

[Gijs007]

code:

root@dal1:~# route -n
Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
10.0.0.0        10.107.86.129   255.0.0.0       UG    0      0        0 eth0
10.107.86.128   0.0.0.0         255.255.255.192 U     0      0        0 eth0
23.246.204.8    0.0.0.0         255.255.255.248 U     0      0        0 br0
root@dal1:~#

Denk het niet aangezien eth1 ontbreekt, of misschien toch wel omdat br0 een bridge is met eth1 en tap0.
eth0 is waar ik op verbind voor de console, en is niet bereikbaar via internet.

[ Voor 13% gewijzigd door Gijs007 op 09-06-2014 22:47 ]

[_root]

Inderdaad, route ontbreekt waarschijnlijk is je gateway de .9
route add -net 0.0.0.0/0 gw 23.246.204.9

[Gijs007]

Klopt gateway is .9
Dan zegt ie, network is unreachable.

[_root]

Gijs007 schreef op maandag 09 juni 2014 @ 22:51:
Klopt gateway is .9
Dan zegt ie, network is unreachable.

geen tikfoutje ?

[Gijs007]

_root schreef op maandag 09 juni 2014 @ 22:53:
[...]


geen tikfoutje ?

* Documentation: https://help.ubuntu.com/
Last login: Mon Jun 9 15:43:57 2014 from 10.1.3.172
root@dal1:~# route add -net 0.0.0.0/0 gw 23.246.209.9
SIOCADDRT: Network is unreachable

Lijkt er niet op, tenzij ik iets over het hoofd zie.

[_root]

Ahhhhh, is zie op je br0 het adres 23.246.204.8 staan, zou dan moeten zijn
route add -net 0.0.0.0/0 gw 23.246.204.9

[_root]

Doet het !

[Gijs007]

Ja die doet het.
ik kan nu 23.246.204.11 pingen.

Maar de VPN kan niet verbinden op 23.246.204.11, ik zal ff naar de openvpn config kijken.

[_root]

een mooie tool om te kijken of verbindingen binnen komen is tcpdump
tcpdump -ni br0

Misschien nog niet geinstalleerd, apt-get install tcpdump

[Gijs007]

Ja de verbinding komen binnen

code:

port 1194
;proto tcp
proto udp
dev tap
;dev tun
;dev-node MyTap
ca ca.crt
cert server.crt
dh dh2048.pem
ifconfig-pool-persist ipp.txt
;server-bridge 10.8.0.4 255.255.255.0 10.8.0.50 10.8.0.100
server-bridge 23.246.204.8 255.255.255.248 23.246.204.11 23.246.204.14
;server-bridge
;push "route 192.168.10.0 255.255.255.0"
push "route 23.246.204.12 255.255.255.248"
;client-config-dir ccd
;route 23.246.204.12 255.255.255.248
;client-config-dir ccd
;route 10.9.0.0 255.255.255.252
;learn-address ./script
push "redirect-gateway def1 bypass-dhcp"
;push "dhcp-option DNS 208.67.222.222"
push "dhcp-option DNS 8.8.8.8"
;client-to-client
;duplicate-cn
keepalive 10 120
;max-clients 100
;user nobody
;group nogroup
persist-key
persist-tun
status openvpn-status.log
;log         openvpn.log
;log-append  openvpn.log
verb 3
;mute 20

[ Voor 91% gewijzigd door Gijs007 op 09-06-2014 23:12 ]

[_root]

server-bridge 23.246.204.8 255.255.255.248 23.246.204.11 23.246.204.14
je geeft hier een .8 op, dat is het netwerk ID , vervang eens voor de .12 en vervang de 23.246.204.11 vor de 23.246.204.13

server-bridge 23.246.204.12 255.255.255.248 23.246.204.13 23.246.204.14

[Gijs007]

Done, dan krijg ik:

Pinging 23.246.204.11 with 32 bytes of data:
Reply from 23.246.204.11: bytes=32 time=117ms TTL=45
Reply from 23.246.204.11: bytes=32 time=117ms TTL=45
Reply from 23.246.204.11: bytes=32 time=118ms TTL=45
Reply from 23.246.204.11: bytes=32 time=117ms TTL=45

Ping statistics for 23.246.204.11:
Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
Minimum = 117ms, Maximum = 118ms, Average = 117ms

C:\Users\Gijs
> ping 23.246.204.12

Pinging 23.246.204.12 with 32 bytes of data:
Reply from 23.246.204.11: Destination host unreachable.
Reply from 23.246.204.11: Destination host unreachable.

Ping statistics for 23.246.204.12:
Packets: Sent = 2, Received = 2, Lost = 0 (0% loss),
Control-C
^C
C:\Users\Gijs
> ping 23.246.204.13

Pinging 23.246.204.13 with 32 bytes of data:
Reply from 23.246.204.11: Destination host unreachable.
Reply from 23.246.204.11: Destination host unreachable.
Reply from 23.246.204.11: Destination host unreachable.
Reply from 23.246.204.11: Destination host unreachable.

Ping statistics for 23.246.204.13:
Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),

De VPN kan wel verbinden en krijgt dan .13
Maar ik kan hem dan nog steeds niet pingen.

[ Voor 3% gewijzigd door Gijs007 op 09-06-2014 23:21 ]

[_root]

Dit is van de client openvpn?
welk adres heeft de client gekregen ?
Zo te zien een windows client?! volgens mij was daar wat mee.... even zoeken

[Gijs007]

Die ping kwam van mijn eigen PC.
de client kreeg het .13 adres, maar nadat deze was toegezegd kon ik die nog steeds niet pingen.

De client is overigens ook een Windows pc, maar ik draai niet de officiële openvpn client maar Viscosity.

quote van https://ipredator.se/guide/openvpn/windows8/viscosity
"Viscosity is a commercial OpenVPN client, which handles administrator permissions properly and thus adjusts the routing table correctly. It is therefore recommended on Windows. "

[ Voor 7% gewijzigd door Gijs007 op 09-06-2014 23:28 ]

[_root]

als je een tcpdump start op de linuxserver met tcpdump -ni tap0
en dan eens een ping doet van de windows client ?
zie je dan het verkeer langskomen ?

[Gijs007]

Ik krijg dan de melding dat tap0 niet up is..

[_root]

openvpn --mktun --dev tap0
ifconfig tap0 23.246.204.12/29 promisc up
brctl addif br0 tap0


kan je dan nog een die tcpdump -ni tap0 starten?
Ik heb een ping staan, moet wat over heen gaan, ook al is het maar een arp

[ Voor 42% gewijzigd door _root op 09-06-2014 23:42 ]

[Gijs007]

eerste 2 werden correct uitgevoerd de laatste niet, omdat die al een member is.

Overigens kan ik IP .12 kan ik nu wel pingen.

Er komt geen verkeer langs volgens tcpdump.

[_root]

kan je wel vanaf de linux server pingen? en zie je dat verkeer over de tap0 ?

Ook nog verbinding met de vpnserver?

[ Voor 21% gewijzigd door _root op 09-06-2014 23:48 ]

[Gijs007]

Wat bedoel je met vanaf de linux server pingen? bedoel je dat de server zich zelf pingt?

[_root]

de andere kant, dus de .13

[Gijs007]

Ahh je bedoelt dat ik vanaf de VPN client ping?

[_root]

nee, vanaf de server de client pirngen, die zou de .13 moeten hebben

[Gijs007]

nee dat doet die ook niet, dan krijg ik weer die destination host unreachable van af .11

[_root]

Als je 2 sessie openzet , op de 1 een ping versturen naar de .13 op de andere sessie tcpdump -ni tap0

[Gijs007]

Ik had toevallig al 2 sessies draaien.
Maar er kwam geen verkeer langs tap0 volgens tcpdump.

[_root]

Op zich is dat al vreemd, windows clients hebben toch behoorlijk de neiging om zich te melden op het netwerk, lijkt to ergens niet goed te gaan met de openvpn config, of op de client of op de server...

ook op de windows kant voor een bridge gekozen ?

[ Voor 11% gewijzigd door _root op 10-06-2014 00:04 ]

[Gijs007]

Denk dat het een server issue is, aangezien ik aan de client niks heb verandert en deze eerst wel werkte en ook verkeer ontving dat aangevraagd was door de client(webbrowsen), maar ik hem toen niet kon pingen van buiten af en ook geen verbinding kon opzetten met de game servers die er op draaien.

[_root]

Maar ook aan de client kant moet je vertellen dat je een tap gebruikt in plaats van een tun, verschil tussen laag 2 en 3 !
Dus kijk naar de client!

[Gijs007]

Klopt, toen ik dit niet had aangepast krijg ik netjes een foutmelding in de log van de client.
Dus ik had hem al ingesteld als tap.

[_root]

Maar er lijkt wel wat veranderd, krijg geen host unreachables meer van de .11 bij een ping..

[Gijs007]

Dat klopt, dat werkte al sinds we de wijziging in de routing hadden gedaan. een pagina terug.

maar als ik .13 ping dan stuurt .11 een reply dat de host unreachable is.

[_root]

ik ping ook de .13, krijg niets meer terug, nog geen verkeer over de tap0 interface ?

[Gijs007]

Vreemd ik krijg nu ook niks terug, er is nog steeds geen verkeer op de tap0

[_root]

Ik ga kijken of ik morgen even je setup kan nabouwen, nu luiken dicht... morgen weer een wekker om 06:00

[Gijs007]

Dit is prima alvast bedankt voor de hulp

[_root]

We zijn een heel eind, laatste stukje nog

[johnkeates]

Gijs007 schreef op maandag 09 juni 2014 @ 18:20:
[...]

Waarom is dat beter?

Om dat Linux de enslaved interface niet meer goed configureert als het de 1e bridge interface is waar de bridge mee opgestart wordt Geeft allerlei problemen met routing en switching (dat laatste doordat de MAC-adressen op bridges gekopieerd worden van de enslaved interfaces, en een dubbele MAC dus alles gaat kopiëren of alles negeert). Er waren nog wel een shitload aan problemen als je een permanente enslaved bridge port misbruikt buiten de bridge om, maar dat weet ik niet meer allemaal uit mijn hoofd.

Op het moment dat je ethX als 1e enslaved bridge port gebruikt kan je hem beter direct als bridge manual instellen. Zo bijvoorbeeld:

code:

allow-hotplug eth0
iface eth0 inet manual

auto wanbr0
iface wanbr0 inet static
        address 123.123.123.123
        netmask 255.255.255.0
        network 123.123.123.0
        broadcast 123.123.123.255
        gateway123.123.123.1
        # dns-* options are implemented by the resolvconf package, if installed
        dns-nameservers 8.8.8.8 #of een andere DNS server als je dat leuk vind
        dns-search domein.com #of een ander zoekdomein, of lekker weglaten
        bridge_ports eth0 #Dit is je uplink die we een stukje hoger op manual gezet hebben
        bridge_stp off #only 1 bridge in this network
            bridge_waitport 0    # not waiting for ports
            bridge_fd 0          # forwarding delay, do not want

Dan weet je zeker dat je geen problemen met briding/routing/switching krijgt, en dat NetFilter in de kernel de juiste pakketjes bewerkt. Als je dan extra IP's toe wil voegen op die bridge kan je natuurlijk daar wel interface aliases op maken, of anders dummy interfaces en die aan je bridge aansluiten, bijvoorbeeld:

code:

auto vip1 #virtual IP 1
iface vip1 inet manual
        pre-up    brctl addif wanbr0 $IFACE
        up        ifconfig    $IFACE up
        down      ifconfig    $IFACE down
        post-down brctl delif wanbr0 $IFACE
        address 123.123.123.124
        netmask 255.255.255.0
        network 123.123.123.0
        broadcast 123.123.123.255
        gateway123.123.123.1

(dit schud ik even uit mijn mouw, het kan zijn dat je de volgorde van de pre-up en up commando's wil aanpassen)

[Gijs007]

@johnkeates

Is dat direct in de /etc/network/interfaces ?

[Gijs007]

bump

[johnkeates]

Ja, dat is in /etc/network/interfaces

Edit: als je je VPS alleen maar voor VPN tunneling wil gebruiken, en je daar zelf een OS op kan installeren, is het dan niet een stuk eenvoudiger om gewoon pfSense te installeren?

[ Voor 71% gewijzigd door johnkeates op 15-06-2014 13:59 ]