- •Credits
- •About the Author
- •About the Reviewers
- •www.PacktPub.com
- •Table of Contents
- •Preface
- •Introduction
- •Shortest setup possible
- •OpenVPN secret keys
- •Multiple secret keys
- •Plaintext tunnel
- •Routing
- •Configuration files versus the command-line
- •Complete site-to-site setup
- •3-way routing
- •Introduction
- •Setting up the public and private keys
- •Simple configuration
- •Server-side routing
- •Routing: subnets on both sides
- •Redirecting the default gateway
- •Using an 'ifconfig-pool' block
- •Using the status file
- •Management interface
- •Proxy-arp
- •Introduction
- •Simple configuration—non-bridged
- •Enabling client-to-client traffic
- •Bridging—Linux
- •Bridging—Windows
- •Checking broadcast and non-IP traffic
- •External DHCP server
- •Using the status file
- •Management interface
- •Introduction
- •Certificate generation
- •xCA: a GUI for managing a PKI (Part 1)
- •xCA: a GUI for managing a PKI (Part 2)
- •OpenSSL tricks: x509, pkcs12, verify output
- •Revoking certificates
- •The use of CRLs
- •Checking expired/revoked certificates
- •Intermediary CAs
- •Multiple CAs: stacking, using --capath
- •Introduction
- •Initializing a hardware token
- •Getting a hardware token ID
- •Using a hardware token
- •Selecting a PKCS#11 certificate using the management interface
- •Generating a key on the hardware token
- •Private method for getting a PKCS#11 certificate
- •Pin caching example
- •Introduction
- •Using a client-side up/down script
- •Windows login greeter
- •Using client-connect/client-disconnect scripts
- •Using a 'learn-address' script
- •Using a 'tls-verify' script
- •Using an 'auth-user-pass-verify' script
- •Script order
- •Script security and logging
- •Using the 'down-root' plugin
- •Using the PAM authentication plugin
- •Introduction
- •Cipher mismatches
- •TUN versus TAP mismatches
- •Compression mismatches
- •Key mismatches
- •Troubleshooting MTU and tun-mtu issues
- •Troubleshooting network connectivity
- •How to read the OpenVPN log files
- •Introduction
- •The missing return route
- •Missing return routes when 'iroute' is used
- •Source routing
- •Routing and permissions on Windows
- •Troubleshooting client-to-client traffic routing
- •Understanding the 'MULTI: bad source' warnings
- •Failure when redirecting the default gateway
- •Introduction
- •Optimizing performance using 'ping'
- •OpenSSL cipher speed
- •Compression tests
- •Traffic shaping
- •Tuning UDP-based connections
- •Tuning TCP-based connections
- •Analyzing performance using tcpdump
- •Introduction
- •Linux: using NetworkManager
- •MacOS: using Tunnelblick
- •Windows Vista/7: elevated privileges
- •Windows: using the CryptoAPI store
- •Windows: updating the DNS cache
- •Windows: running OpenVPN as a service
- •Windows: public versus private network adapters
- •Windows: routing methods
- •Introduction
- •Including configuration files in config files
- •Details of ifconfig-pool-persist
- •Connecting using a SOCKS proxy
- •Connecting via an HTTP proxy
- •Connecting via an HTTP proxy with authentication
- •Using dyndns
- •IP-less setups (ifconfig-noexec)
- •Introduction
- •Inline certificates
- •Connection blocks
- •Port sharing with an HTTPS server
- •Routing features: redirect-private, allow-pull-fqdn
- •OCSP support
- •New for 2.2: the 'x509_user_name' parameter
- •Index
Chapter 3
Bridging—Windows
This recipe will demonstrate how to set up a bridged OpenVPN server on Windows. Bridging on Windows is slightly different from Linux or UNIX, but the concept is the same.
This recipe is very similar to the previous recipe, apart from the different methods used to set up bridging.
Getting ready
We use the following network layout:
Set up the client and server certificates using the first recipe from Chapter 2, Client-server IPonly networks.
For this recipe, the server computer was running Windows XP and OpenVPN 2.1.1. The client computer was running Fedora 12 Linux and OpenVPN 2.1.1. For the Linux client, keep the client configuration file example3-1-client.conf at hand.
How to do it...
1.Create the server configuration file:
proto udp port 1194 dev tap
dev-node tap-bridge
server-bridge 172.30.0.50 255.255.255.0 172.30.0.80 170.32.0.250
83
Client-server Ethernet-style Networks
ca |
"c:/program files/openvpn/config/ca.crt" |
cert |
"c:/program files/openvpn/config/server.crt" |
key |
"c:/program files/openvpn/config/server.key" |
dh |
"c:/program files/openvpn/config/dh1024.pem" |
tls-auth "c:/program files/openvpn/config/ta.key" 0 push "route 172.30.0.0 255.255.255.0"
persist-key persist-tun keepalive 10 60
Save it as example-3-4-server.conf.
2.Next, create the network bridge:
Each TAP-Win32 adapter on Windows is assigned a name like Local Area Connection 2. Go to the Network Connections control panel and rename it to tap-bridge.
Next, select tap-bridge and your Ethernet adapter with the mouse, right click, and then select Bridge Connections:
This will create a new bridge adapter icon in the control panel, usually named
Network Bridge (…).
84
Chapter 3
3. The network bridge is now ready to be configured:
4. In a command window, verify that the bridge is configured correctly:
[winserver]C:> netsh interface ip show address "Network Bridge"
Configuration for interface "Network Bridge"
DHCP enabled: |
No |
IP Address: |
172.30.0.50 |
SubnetMask: |
255.255.255.128 |
Default Gateway: |
172.30.0.1 |
GatewayMetric: |
5 |
InterfaceMetric: |
0 |
5. Start the OpenVPN server:
[winserver]C:> cd \program files\openvpn\config [winserver]C:> ..\bin\openvpn --config example3-4-server.ovpn
85
Client-server Ethernet-style Networks
6. Start the client:
[root@client]# openvpn --config example3-1-client.conf
7.Now, check the assigned VPN address and verify that we can ping a machine on the remote server LAN:
[client]$ /sbin/ifconfig tap1
tap1 Link encap:Ethernet HWaddr A2:F4:D4:E7:99:CF inet addr:172.30.0.80 Bcast:172.30.0.255 Mask:255.255.255.0
[…]
[client]$ ping -c 2 172.30.0.12
PING 172.30.0.12 (172.30.0.12) 56(84) |
bytes of data. |
||
64 |
bytes from 172.30.0.12: icmp_seq=1 |
ttl=128 |
time=24.0 ms |
64 |
bytes from 172.30.0.12: icmp_seq=2 |
ttl=128 |
time=26.0 ms |
How it works...
Apart from the way the bridge is created and configured, this recipe is very similar to the previous one. The one thing to keep in mind is how the adapter is selected in the server configuration file:
dev tap
dev-node tap-bridge
On Linux and other UNIX variants, this could be achieved using a single line:
dev tap0
But the naming scheme for the TAP adapters on Windows is different. To overcome this, the dev-node directive needs to be added.
See also
The previous recipe, where bridging on Linux is explained.
Checking broadcast and non-IP traffic
The main reason for a bridged setup is to create a single broadcast domain for all clients connected, both via the VPN and via a regular network connection.
Another reason is the ability to route or forward non-IP based traffic, such as the older Novell
IPX and Appletalk protocols.
This recipe focuses on the use of tools such as tcpdump and wireshark to detect whether the broadcast domain is functioning and if non-IP traffic is flowing in the correct manner.
86
Chapter 3
Getting ready
For this recipe, we use the setup from the recipe Bridging—Linux of this chapter. We use the following network layout:
I |
For this recipe, the server computer was running Fedora 12 Linux and OpenVPN 2.1.1. For the server, keep the server configuration file example3-3-server.conf from the recipe Bridging—Linux ready. The first client computer was running Windows 2000 and was in the same LAN segment as the OpenVPN server. The second client was running Windows XP and
OpenVPN 2.1.1. For this client, keep the client configuration file example3-2-client2.ovpn from the recipe Enabling client-to-client traffic at hand.
Make sure that the Appletalk and IPX protocols are installed on both Windows machines. Bind the protocols to the Local Area Network adapters (this is the default setting).
How to do it...
1. Create the network bridge and verify that it is working:
[root@server]# bash example3-3-bridge-start
TUN/TAP device tap0 opened Persist state set to: ON
[root@server]# brctl show
bridge name bridge id |
STP enabled interfaces |
||
br0 |
8000.00219bd2d422 no |
eth0 |
|
|
|
|
tap0 |
87
Client-server Ethernet-style Networks
2. Start the OpenVPN server:
[root@server]# openvpn --config example3-3-server.conf
3. Start the OpenVPN clients:
[WinClient1]C:> cd \program files\openvpn\config [WinClient1]C:> ..\bin\openvpn --config example3-2-client2.ovpn
Client 2:
In this recipe, the Windows 2000 client was assigned 192.168.4.64. The Windows XP client was assigned 192.168.4.128.
4.After the client has successfully connected, we first check for ARP messages. On the server, run tcpdump and listen for traffic on the bridge interface br0:
In this output, 192.168.4.254 is the address of the server-side gateway. So, the gateway is asking for ARP information and the ARP replies are coming from both the OpenVPN server and the OpenVPN client itself. This can only happen if the ARP request is forwarded over the bridge to the OpenVPN client.
88
Chapter 3
5.Next, on the Windows 2000 client, check for the broadcast traffic coming from the Windows XP client. For this, we use Wireshark. Wireshark is available for both Linux and Windows. Configure Wireshark to capture all the traffic from the
Ethernet adapter.
In this output, we see a lot of Netbios broadcast traffic when the OpenVPN client first connects to the network.
89