Check alle échte Black Friday-deals Ook zo moe van nepaanbiedingen? Wij laten alleen échte deals zien

VPN Bridge: Wel IP, geen data

Pagina: 1
Acties:

  • NjitsSs
  • Registratie: Oktober 2007
  • Laatst online: 07:01
Goedenavond Dames en Heren,

Op m'n werk heb ik een PFSense firewall waarop ook een OpenVPN server draait. Ik verbind nu dmv een TUN device, en dat werkt allemaal naar behoren.

Er is echter een applicatie die ik ook van thuis uit zou willen kunnen gebruiken, en die applicatie maakt gebruik van floating netwerk licenties. De applicatie vindt z'n licentieserver dmv broadcast data, en die geraakt niet door de tunnel.
Om dit op te lossen wilde ik een 2e OpenVPN server opzetten, deze keer met een TAP device zodat de VPN client gebridged wordt met het LAN.

Wat ik gedaan heb:
  • Een nieuwe VPN server toegevoegd
  • Device op TAP, Bridge Interface op "LAN", Redirect Gateway opgezet. Klik hier voor een screenshot van de settings
  • Een firewall rule toegevoegd zodat ik kan verbinden met de VPN server
  • Een bridge gemaakt tussen de OpenVPN interface en 't LAN
Als client gebruik ik m'n Macbookje met Tunnelblick als VPN client. Na het verbinden wordt er een tap0 device aangemaakt:
code:
1
2
3
4
5
CrapBook-Pro:~ MyUserName$ ifconfig tap0
tap0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> mtu 1500
    ether 72:47:e1:ee:da:99 
    inet 172.16.200.68 netmask 0xffff0000 broadcast 172.16.255.255
    open (pid 35286)

172.16.0.0/16 is inderdaad de IP range van 't office LAN.
En in 't logboek van Tunnelblick wordt ook 't juiste search domain en WINS server vermeld. De DHCP request lijkt me bijgevolg goed te gaan.

Echter meldt Tunnelblick me dat het "apparent public IP" van m'n computer niet veranderd is, en pingen naar eender welke computer op 't LAN van 't werk (inclussief de PFsense server) is niet mogelijk.
Het valt me op dat het tap0 device geen default gateway heeft.

OpenVPN client log:
code:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
2014-11-09 22:51:00 *Tunnelblick: OS X 10.9.5; Tunnelblick 3.4.1 (build 4054); prior version 3.4.0 (build 4007)
2014-11-09 22:51:01 *Tunnelblick: Attempting connection with poseidon-udp-1195 using shadow copy; Set nameserver = 1; monitoring connection
2014-11-09 22:51:01 *Tunnelblick: openvpnstart start poseidon-udp-1195.tblk 1338 1 0 1 0 16754 -ptADGNWradsgnw 2.3.4
2014-11-09 22:51:02 *Tunnelblick: openvpnstart log:
     Tunnelblick: Loading tap-signed.kext
     Tunnelblick: 
     OpenVPN started successfully. Command used to start OpenVPN (one argument per displayed line):
     
          /Applications/Tunnelblick.app/Contents/Resources/openvpn/openvpn-2.3.4/openvpn
          --daemon
          --log
          /Library/Application Support/Tunnelblick/Logs/-SUsers-SMyUserName-SLibrary-SApplication Support-STunnelblick-SConfigurations-Sposeidon--udp--1195.tblk-SContents-SResources-Sconfig.ovpn.1_0_1_0_16754.1338.openvpn.log
          --cd
          /Library/Application Support/Tunnelblick/Users/MyUserName/poseidon-udp-1195.tblk/Contents/Resources
          --config
          /Library/Application Support/Tunnelblick/Users/MyUserName/poseidon-udp-1195.tblk/Contents/Resources/config.ovpn
          --cd
          /Library/Application Support/Tunnelblick/Users/MyUserName/poseidon-udp-1195.tblk/Contents/Resources
          --management
          127.0.0.1
          1338
          --management-query-passwords
          --management-hold
          --script-security
          2
          --up
          /Applications/Tunnelblick.app/Contents/Resources/client.up.tunnelblick.sh -m -w -d -a -f -ptADGNWradsgnw
          --down
          /Applications/Tunnelblick.app/Contents/Resources/client.down.tunnelblick.sh -m -w -d -a -f -ptADGNWradsgnw
          --route-pre-down
          /Applications/Tunnelblick.app/Contents/Resources/client.route-pre-down.tunnelblick.sh -m -w -d -a -f -ptADGNWradsgnw

2014-11-09 22:51:01 OpenVPN 2.3.4 x86_64-apple-darwin [SSL (OpenSSL)] [LZO] [PKCS11] [MH] [IPv6] built on Oct 15 2014
2014-11-09 22:51:01 library versions: OpenSSL 1.0.1j 15 Oct 2014, LZO 2.08
2014-11-09 22:51:01 *Tunnelblick: openvpnstart starting OpenVPN
2014-11-09 22:51:02 *Tunnelblick: Established communication with OpenVPN
2014-11-09 22:51:02 *Tunnelblick: Obtained VPN username and password from the Keychain
2014-11-09 22:51:02 NOTE: the current --script-security setting may allow this configuration to call user-defined scripts
2014-11-09 22:51:02 Control Channel Authentication: using 'poseidon-udp-1195-tls.key' as a OpenVPN static key file
2014-11-09 22:51:02 UDPv4 link local (bound): [undef]
2014-11-09 22:51:02 UDPv4 link remote: [AF_INET]84.193.55.204:1195
2014-11-09 22:51:02 WARNING: this configuration may cache passwords in memory -- use the auth-nocache option to prevent this
2014-11-09 22:51:02 [www.MyCompanyName.be] Peer Connection Initiated with [AF_INET]84.193.55.204:1195
2014-11-09 22:51:04 TUN/TAP device /dev/tap0 opened
2014-11-09 22:51:04 /Applications/Tunnelblick.app/Contents/Resources/client.up.tunnelblick.sh -m -w -d -a -f -ptADGNWradsgnw tap0 1500 1589   init
                                        **********************************************
                                        Start of output from client.up.tunnelblick.sh
                                        Configuring tap DNS via DHCP asynchronously
                                        End of output from client.up.tunnelblick.sh
                                        **********************************************
2014-11-09 22:51:06 NOTE: unable to redirect default gateway -- VPN gateway parameter (--route-gateway or --ifconfig) is missing
2014-11-09 22:51:06 Initialization Sequence Completed
                                        Retrieved from DHCP/BOOTP packet: name server(s) [ 172.16.1.4 ], domain name [ MyCompanyName.lan ], search domain(s) [  ] and SMB server(s) [ 172.16.1.2 ]
                                        Not aggregating ServerAddresses because running on OS X 10.6 or higher
                                        Not aggregating WINSAddresses because running on OS X 10.6 or higher
                                        Setting search domains to 'MyCompanyName.lan' because running under OS X 10.6 or higher and the search domains were not set manually and 'Prepend domain name to search domains' was not selected
                                        Saved the DNS and SMB configurations so they can be restored
                                        Set ServerAddresses to 172.16.1.4
                                        Set SearchDomains   to MyCompanyName.lan
                                        Set DomainName       to MyCompanyName.lan
                                        Set WINSAddresses   to 172.16.1.2
                                        Flushed the DNS cache via dscacheutil
                                        Notified mDNSResponder that the DNS cache was flushed
                                        Setting up to monitor system configuration with process-network-changes
2014-11-09 22:51:06 *Tunnelblick: No 'connected.sh' script to execute
                                        Sleeping for 0 seconds to wait for DHCP to finish setup.
                                        Sleeping for 1 seconds to wait for DHCP to finish setup.
                                        Sleeping for 2 seconds to wait for DHCP to finish setup.
2014-11-09 22:51:11 *Tunnelblick: This computer's apparent public IP address (84.193.96.76) was unchanged after the connection was made
2014-11-09 22:51:49 *Tunnelblick process-network-changes: A system configuration change was ignored
2014-11-09 22:52:12 *Tunnelblick: Disconnecting; 'Disconnect' (toggle) menu command invoked
2014-11-09 22:52:12 *Tunnelblick: Disconnecting using 'kill'
2014-11-09 22:52:12 event_wait : Interrupted system call (code=4)
2014-11-09 22:52:12 /Applications/Tunnelblick.app/Contents/Resources/client.route-pre-down.tunnelblick.sh -m -w -d -a -f -ptADGNWradsgnw tap0 1500 1589   init
                                        **********************************************
                                        Start of output from client.route-pre-down.tunnelblick.sh
                                        Cancelled monitoring of system configuration changes
                                        Released the DHCP lease via ipconfig set "tap0" NONE.
                                        End of output from client.route-pre-down.tunnelblick.sh
                                        **********************************************
2014-11-09 22:52:12 /Applications/Tunnelblick.app/Contents/Resources/client.down.tunnelblick.sh -m -w -d -a -f -ptADGNWradsgnw tap0 1500 1589   init
                                        **********************************************
                                        Start of output from client.down.tunnelblick.sh
                                        Restored the DNS and SMB configurations
                                        Flushed the DNS cache via dscacheutil
                                        Notified mDNSResponder that the DNS cache was flushed
                                        End of output from client.down.tunnelblick.sh
                                        **********************************************
2014-11-09 22:52:12 SIGTERM[hard,] received, process exiting
2014-11-09 22:52:13 *Tunnelblick: No 'post-disconnect.sh' script to execute
2014-11-09 22:52:13 *Tunnelblick: Expected disconnection occurred.



Heeft er iemand enig idee hoe ik toch wat data door de OpenVPN connectie geduwd krijg?


Alvast bedankt,

Stijn

  • rxr1991
  • Registratie: Mei 2007
  • Laatst online: 13-10 18:02
Ik ben er zelf ook nog niet helemaal uit als het zou werken maar zou een ssh tunnel geen oplossing zijn. Lijkt me een stuk makkelijker en minder omslachtig.

  • NjitsSs
  • Registratie: Oktober 2007
  • Laatst online: 07:01
Een SSH tunnel is inderdaad een mooie optie, maar krijg dat maar eens netjes aan de praat met Windows clients...

  • johnkeates
  • Registratie: Februari 2008
  • Laatst online: 04-07 16:30
Je moet geen tap krijgen, maar een tun. De interface heet dan utunX waarbij X het nummer is van je volgende interface.

Zo ziet een goed geconfigureerde tunnel er dan uit:

[code]
utun0: flags=8051<UP,POINTOPOINT,RUNNING,MULTICAST> mtu 1500
inet 10.0.9.6 --> 10.0.9.5 netmask 0xffffffff
[/code]


Je routes staan dan ook goed:

[code]
10.11/24 10.0.9.5 UGSc 0 0 utun0
10.0.1/24 10.0.9.5 UGSc 0 0 utun0
10.0.9/24 10.0.9.5 UGSc 0 0 utun0
10.0.9.5 10.0.9.6 UHr 23 0 utun0
[/code]

Als je dan ook een "route all traffic trough VPN" aan hebt staan krijg je nog wat routes er bij, o.a. een 0/1 route over je utun, en een gateway/32 route naar de gateway.

Waarschijnlijk heb je gewoon je configuratie verkeerd staan.


Oh, je wil een L2 bridge opzetten 8)7 had ik even niet gezien.
L2 Bridges zijn weer wat anders ja. Die configuraties zijn net wat anders, maar niet onmogelijk, ik pak 'm er even bij...


Je Peer to Peer moet er zo uit zien:

Server Mode: Peer to Peer (Shared Key)
Protocol: UDP
Device Mode: TAP
Interface: WAN (of waar je uitgaande interface dan ook zit)
Local port: xxxx (maak er wat leuks van, 1024+ is goed, 119x wordt voor OVPN gebruikt)
Description: L2 Bridge
Shared Key: lekker laten genereren
Encryption algorithm: AES-128-CBC
Hardware Crypto: uit
IPv4 Tunnel: buiten je doelsubnet

De rest leeg laten en opslaan.

Daarna: Interfaces -> Assign -> nieuwe interface (plusje)

ovpnsX waarbij X je nieuw gemaakte Open VPN server is, de naam staat er achter.

Interface settings:

Enable: aan
Description: L2BROVPN (of iets anders, verzin maar wat)
IPv4 Config: none
IPv6 Config: none
Block Private: uit
Block Bogon: uit

de rest lekker op standaard waardes laten staan, en opslaan.

Daarna naar Interfaces -> Assign -> Bridges

Nieuwe bridge maken, LAN en VPN interfaces er in knikkeren (en evt. een omschrijving er bij), opslaan.

Vanaf dit punt heb je dus een werkende L2 Bridge met je LAN, en een werkende TAP server.
Alles wat er vanaf nu nog mis kan zijn is je firewall. Dit configureer ik voor L2 Bridges zo:

Firewall -> OpenVPN (ik gebruik alleen IPv4 in dit geval) -> Catch all rule voor pass maken
Firewall -> L2BROVPN (ik gebruik alleen IPv4 in dit geval) -> Catch all rule voor pass maken

Daarna boven op je Catch all rules voor pass eventuele block/drop/reject rules opstapelen. Het punt van een L2 bridge is dat het zo veel mogelijk een 'virtuele ethernet verbinding' is.

Daarna moet het werken.

Hier werkt het met pfSense als gateway aan de ene kant met de volgende clients aan de andere kant:

- Linux met OpenVPN
- Mac OS X met TunnelBlick, Viscosity, OpenVPN
- Windows met OpenVPN
- pfSense

Bij sommige netwerk configuraties werkte het alleen goed als de routetabel goed aangepast werd. Dat kan voor sommige clients betekenen dat je ze zo moet instellen dat al het verkeer over de VPN verbinding moet. In het geval van OS X werkt L2 bridging alleen goed als je in System Preferences bij Network je tunnel ziet. Als je hem daar niet ziet kan je nog even handmatig een extra interface maken en die bridgen met je tunnel. Soms levert dat dubbele vermeldingen in je ifconfig op, maar dat is niet erg.

[ Voor 60% gewijzigd door johnkeates op 16-11-2014 13:15 ]


  • NjitsSs
  • Registratie: Oktober 2007
  • Laatst online: 07:01
Ik heb ook een andere VPN server draaien die een tun interface aanbiedt. Ook daarbij staat de optie "route al traffic through VPN" aan.
code:
1
2
utun0: flags=8051<UP,POINTOPOINT,RUNNING,MULTICAST> mtu 1500
    inet 10.0.8.6 --> 10.0.8.5 netmask 0xffffffff



Echter wordt broadcast data niet gerouteerd over een VPN verbinding, waardoor o.a. de licentieserver van het programma dat ik wil gebruiken niet gevonden kan worden. Daarom dat ik aan het kijken was voor een VPN met tap interface.

[ Voor 6% gewijzigd door NjitsSs op 16-11-2014 13:33 ]


  • Thralas
  • Registratie: December 2002
  • Laatst online: 23:39
code:
1
2014-11-09 22:51:06 NOTE: unable to redirect default gateway -- VPN gateway parameter (--route-gateway or --ifconfig) is missing


Zit hier het probleem niet?

'route-gateway dhcp' lijkt me juist in jouw geval, en dat wordt gepushed door de server als je daar 'server-bridge' specificeert.

[ Voor 27% gewijzigd door Thralas op 16-11-2014 14:31 ]


  • Brabix
  • Registratie: April 2012
  • Laatst online: 30-06 17:49
Misschien dat ik een stomme opmerking maak, maar is het niet mogelijk om in software die je wilt gebruiken (of in de driver voor de netwerk dongle licentie) aan te geven bij welk ip adres hij de licentie op moet halen?

Voor bijvoorbeeld HASP is dit perfect mogelijk. Op pagina 11 van dit document staat een uitleg: http://www.rubomedical.co...rkLicenseInstallation.pdf

Dit is misschien wel voor andere software, maar indien de software die je wilt gebruiken HASP gebruikt is het proces hetzelfde. Indien er gebruikt gemaakt wordt van een andere licentie provider dan HASP is dit misschien ook wel mogelijk. Scheelt je een hoop moeite vergeleken met het aanpassen van je VPN.

  • johnkeates
  • Registratie: Februari 2008
  • Laatst online: 04-07 16:30
Heb je de rest van mijn post ook gelezen?

  • NjitsSs
  • Registratie: Oktober 2007
  • Laatst online: 07:01
Ik ben dit topic een beetje uit het oog verloren, mijn excuses alvast voor het late antwoord.


Met de uitgebreide uitleg van Johnkeates ben ik ondertussen in geslaagd om het systeem werkend te krijgen. De applicatie vindt probleemloos zijn licentieserver.
Wel moet ik aanvullen dat ik manueel de metric van de TAP interface op de VPN client heb moeten verlagen, lager dan de LAN interface. Als je dit niet doet, worden broadcasts nog steeds verstuurd op het LAN, en niet via de VPN.

Waar ik nu nog tegenaan loop is dat ik het hele office netwerk kan bereiken, alleen niet de server waar OpenVPN op draait.
Het lijkt er op dat wat van de VPN komt via bridge0 rechtstreeks naar het LAN gaat, en niet aan komt op de LAN interface van de PFsense bak.
Moet er misschien nog een loopback interface ofzo bij in de bridge om dit te laten werken?
Pagina: 1