- •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
Client-server Ethernet-style Networks
6. As a final example, we look for IPX traffic:
This shows that non-IP traffic is also forwarded over the bridge.
How it works...
All traffic that is forwarded over the bridge is intercepted by programs like Wireshark. By filtering for certain types of traffic, it is easy to show that in a bridged setup traffic from the OpenVPN clients is indeed flowing over the server-side LAN. This is very important when troubleshooting an "almost-working" setup.
External DHCP server
In this recipe, we will configure a bridged OpenVPN server so that it uses an external DHCP server to assign addresses to the OpenVPN clients to further increase the integration of remote clients with the clients already present on the server-side LAN.
90
Chapter 3
Getting ready
We use the following network layout:
Set up the client and server certificates using the first recipe from Chapter 2, Client-server IP-only Networks.
For this recipe, the server computer was running Fedora 12 Linux and OpenVPN 2.1.1. The client was running Windows XP SP3 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.
How to do it...
1.Create the server configuration file:
proto udp port 1194 dev tap0
server-bridge
push "route 0.0.0.0 255.255.255.255 net_gateway"
ca |
/etc/openvpn/cookbook/ca.crt |
cert |
/etc/openvpn/cookbook/server.crt |
key |
/etc/openvpn/cookbook/server.key |
dh |
/etc/openvpn/cookbook/dh1024.pem |
tls-auth /etc/openvpn/cookbook/ta.key 0
persist-key persist-tun
91
Client-server Ethernet-style Networks
keepalive 10 60
user nobody group nobody
daemon
log-append /var/log/openvpn.log
and save it as example3-6-server.conf. 2. Start the server:
[root@server]# openvpn --config example3-6-server.conf
3. Start the Windows client:
4. After the VPN connection is established, verify the IP address and the routing tables:
[WinClient]C:> ipconfig /all
[…]
Ethernet adapter tapwin32-0 Connection-specific DNS Suffix . : lan
Description . . . . . . . . . . . : TAP-Win32 Adapter V9 Physical Address. . . . . . . . . : 00-FF-17-82-55-DB Dhcp Enabled. . . . . . . . . . . : Yes Autoconfiguration Enabled . . . . : Yes
IP Address. . . . . . . . . . . . : 192.168.4.66
Subnet Mask . . . . . . . . . . . : 255.255.255.0
Default Gateway . . . . . . . . . : 192.168.4.254
DHCP Server . . . . . . . . . . . : 192.168.4.254
DNS Servers . . . . . . . . . . . : 192.168.4.254 […]
92
Chapter 3
[WinClient]C:> netstat -rn |
|
|
|
|
[…] |
|
|
|
|
0.0.0.0 |
0.0.0.0 |
172.30.1.2 |
172.30.1.131 |
10 |
0.0.0.0 |
255.255.255.255 |
172.30.1.2 |
172.30.1.131 |
1 |
0.0.0.0 |
0.0.0.0 |
192.168.4.254 192.168.4.66 |
1 |
|
Default Gateway: |
172.30.1.2 |
|
|
|
[…] |
|
|
|
|
5. And finally, we check that we can reach other hosts in the server-side LAN:
[WinClient]C:> ping 192.168.4.64
Pinging 192.168.4.64 with 32 bytes of data:
Reply from 192.168.4.64: bytes=32 time=3ms TTL=64
Reply from 192.168.4.64: bytes=32 time=1ms TTL=64
Reply from 192.168.4.64: bytes=32 time=1ms TTL=64
Reply from 192.168.4.64: bytes=32 time<1ms TTL=64
How it works...
The server directive:
server-bridge
Without any parameters this instructs OpenVPN to not allocate a pool of IP addresses for the clients. So, all the incoming DHCP requests from the clients are forwarded out over the bridge. The DHCP server on the server-side LAN then replies with an IP address.
The tricky part here is that the DHCP server almost always also returns a default gateway, which will be the LAN gateway. If a remote client sets its default gateway to the gateway of the LAN, funny things will happen, as in most cases, the direct route to the OpenVPN server is lost.
The following directive instructs the OpenVPN client to add an explicit "default" route via the net_gateway, which is always the LAN gateway at the client side:
push "route 0.0.0.0 255.255.255.255 net_gateway"
For Windows clients, this trick works and the default gateway remains intact.
For Linux clients, it is easier to tweak the dhclient and network-scripts settings. However, this is distribution dependent.
With the default gateway intact, the OpenVPN client is properly assigned an address from the DHCP server on the server side.
93
Client-server Ethernet-style Networks
There's more...
DHCP server configuration
The proper solution is to configure the DHCP server such that DHCP requests from the VPN clients do not get a default gateway assigned. This adds a burden to the administration of the server-side DHCP server.
In this case, it also makes sense to explicitly set a unique MAC address in each client configuration file using, for example:
lladdr CA:C6:F8:FB:EB:3B
On Linux, the MAC address is computed randomly when the TAP interface comes up, so each time the OpenVPN client is stopped and started, a new IP address is allocated. It is also possible to create a permanently-fixed MAC address by bringing up the TAP device using the system configuration scripts before OpenVPN starts.
Windows TAP devices also have a randomized initial MAC address, but this can only be changed using a Windows registry editor.
DHCP relay
It is also possible to use an external DHCP server without using bridging. If the TAP adapter is configured before OpenVPN is started and the server configuration file from this recipe is used then an external DHCP server can be used using the Linux dhrelay command:
[root@server]# dhrelay -i tap0 -i eth0
Make sure to list both the TAP adapter and the Ethernet adapter to which the external DHCP server is connected. By combining this with a proxy-arp script (see Chapter 2's recipe, Proxy ARP), it eliminates the need to use bridging in most cases.
Tweaking the /etc/sysconfig/network-scripts
On RedHat, Fedora, and OpenSuSE-based systems, the TAP adapter is brought up using a script /etc/sysconfig/network-scripts/ifup-tap0 and the command:
[root@client]# /sbin/ifup tap0
By adding the line to the /etc/sysconfig/network-scripts/ifup-tap0 file, the dhclient script ignores the gateway that is assigned from the DHCP server:
GATEWAYDEV=eth0
A similar hack can be developed for Debian/Ubuntu-based systems.
94