Jesus. It's only the second week of school and I've already pulled my first all-nighter. This time, however, it was not for school. I was determined to get my OpenVPN server properly setup so that I could finally browse the web securely from the dorms. I only expected this to take a few minutes, but I ended up spending over 7 hours of research, troubleshooting, and configuration changes.
This post will contain a slew of information about smoothwall, zerina, openvpn, and iptables. I'm mostly just going to throw all of my findings here without much of any logical flow.
Setup
I have a smoothwall firewall at my house with the zerina addin installed for managing my openvpn server. I have a client across town behind a packet shaped, double NATed, terribly insecure, and poorly configured dorm network. I wanted to have all of my internet traffic on the client go through an encrypted tunnel to my home network so I can do my online banking from the dorms with some peace of mind.
24.99.218.183 - Home IP Address
168.28.136.13 - Dorm IP Address
Issue
What was initially supposed to be a 10 second operation (type your password and connect) got ruined when I first saw this error message:
Tue Jan 20 02:47:11 2009 read UDPv4 [ECONNREFUSED]: Connection refused (code=111) ( ^ this line repeated several times ^ ) ... TLS Error: TLS key negotiation failed to occur within 60 seconds (check your network connectivity)
Unfortunately, this is probably the most common openvpn client-side error.
According to the typically excellent openvpn documentation's FAQs section
I'm getting this error: TLS Error: TLS key negotiation failed to occur within 60 seconds (check your network connectivity)
One of the most common problems in setting up OpenVPN is that the two OpenVPN daemons on either side of the connection are unable to establish a TCP or UDP connection with each other.
This is almost [always] a result of:
* A perimeter firewall on the server's network is filtering out incoming OpenVPN packets (by default OpenVPN uses UDP or TCP port number 1194).
* A software firewall running on the OpenVPN server machine itself is filtering incoming connections on port 1194. Be aware that many OSes will block incoming connections by default, unless configured otherwise.
* A NAT gateway on the server's network does not have a port forward rule for TCP/UDP 1194 to the internal address of the OpenVPN server machine.
* The OpenVPN client config does not have the correct server address in its config file. The remote directive in the client config file must point to either the server itself or the public IP address of the server network's gateway.
* Another possible cause is that the windows firewall is blocking access for the openvpn.exe binary. You may need to whitelist (add it to the "Exceptions" list) it for OpenVPN to work.
Well, I'm not running a windows machine on either the client or the server, so that ruled out the last one.
Also, things are simplified because the smoothwall firewall is the OpenVPN server.
Anyway, it sounded like a configuration issue with either OpenVPN, my home's firewall, or my dorm's firewall. Spoiler Alert: it was my home's firewall. If you don't give a shit (you probably don't) just skip the Debugging Section and move straight to the Resolution Section.
Debugging
TLS Error: TLS key negotiation failed to occur within 60 seconds
Completely ignoring the fact that 60 seconds is a long-ass time, I falsely assumed that this error was a timeout issue. To rule this out, I decided to push the 60 seconds cap to something even more incredibly unreasonable: 999 seconds (16min+39sec).
So, I added the following flag to my openvpn client configuration file:
tls-timeout 999
ping-restart
However, my change didn't have the desired results.
# openvpn guttersnipe-TO-SW.ovpn Tue Jan 20 02:35:48 2009 OpenV-->PN 2.1_rc7 x86_64-pc-linux-gnu [SSL] [LZO2] [EPOLL] built on Jun 11 2008 Tue Jan 20 02:35:48 2009 IMPORTANT: OpenVPN's default port number is now 1194, based on an official port number assignment by IANA. OpenVPN 2.0-beta16 and earlier used 5000 as the default port. Enter Private Key Password: Tue Jan 20 02:35:51 2009 WARNING: file 'guttersnipe.p12' is group or others accessible Tue Jan 20 02:35:51 2009 /usr/bin/openssl-vulnkey -q -b 1024 -m Tue Jan 20 02:35:51 2009 WARNING: normally if you use --mssfix and/or --fragment, you should also set --tun-mtu 1500 (currently it is 1400) Tue Jan 20 02:35:51 2009 Control Channel MTU parms [ L:1441 D:138 EF:38 EB:0 ET:0 EL:0 ] Tue Jan 20 02:35:51 2009 Data Channel MTU parms [ L:1441 D:1441 EF:41 EB:4 ET:0 EL:0 ] Tue Jan 20 02:35:51 2009 Local Options hash (VER=V4): '57657c3f' Tue Jan 20 02:35:51 2009 Expected Remote Options hash (VER=V4): '778eeec5' Tue Jan 20 02:35:51 2009 Socket Buffers: R=[122880->131072] S=[122880->131072] Tue Jan 20 02:35:51 2009 UDPv4 link local (bound): [undef]:1194 Tue Jan 20 02:35:51 2009 UDPv4 link remote: 24.99.218.183:1194 Tue Jan 20 02:35:51 2009 read UDPv4 [ECONNREFUSED]: Connection refused (code=111) ( ^ this line repeats several dozen times ^ ) ... Tue Jan 20 02:37:52 2009 [UNDEF] Inactivity timeout (--ping-restart), restarting Tue Jan 20 02:37:52 2009 TCP/UDP: Closing socket Tue Jan 20 02:37:52 2009 SIGUSR1[soft,ping-restart] received, process restarting Tue Jan 20 02:37:52 2009 Restart pause, 2 second(s) Tue Jan 20 02:37:54 2009 IMPORTANT: OpenVPN's default port number is now 1194, based on an official port number assignment by IANA. OpenVPN 2.0-beta16 and earlier used 5000 as the default port. ...
OpenVPN has two flags to maintain a keep-alive: ping and a ping-restart. A ping is sent to the server at an interval as specified by ping. The ping-restart flag will force the connection to be restarted if the client doesn't receive a ping from the server within a set amount of time (default = 60sec). ping-restart can be disabled by setting it to zero (0).
To override these, I added the following two flags to my client configuration file:
ping 999 ping-restart 0
timeout
Finally, I found that I still got a timeout after 999 seconds.
# openvpn guttersnipe-TO-SW.ovpn Tue Jan 20 02:47:04 2009 OpenVPN 2.1_rc7 x86_64-pc-linux-gnu [SSL] [LZO2] [EPOLL] built on Jun 11 2008 Tue Jan 20 02:47:04 2009 IMPORTANT: OpenVPN's default port number is now 1194, based on an official port number assignment by IANA. OpenVPN 2.0-beta16 and earlier used 5000 as the default port. Enter Private Key Password: Tue Jan 20 02:47:10 2009 WARNING: file 'guttersnipe.p12' is group or others accessible Tue Jan 20 02:47:10 2009 /usr/bin/openssl-vulnkey -q -b 1024 -m Tue Jan 20 02:47:11 2009 WARNING: normally if you use --mssfix and/or --fragment, you should also set --tun-mtu 1500 (currently it is 1400) Tue Jan 20 02:47:11 2009 Control Channel MTU parms [ L:1441 D:138 EF:38 EB:0 ET:0 EL:0 ] Tue Jan 20 02:47:11 2009 Data Channel MTU parms [ L:1441 D:1441 EF:41 EB:4 ET:0 EL:0 ] Tue Jan 20 02:47:11 2009 Local Options hash (VER=V4): '57657c3f' Tue Jan 20 02:47:11 2009 Expected Remote Options hash (VER=V4): '778eeec5' Tue Jan 20 02:47:11 2009 Socket Buffers: R=[122880->131072] S=[122880->131072] Tue Jan 20 02:47:11 2009 UDPv4 link local (bound): [undef]:1194 Tue Jan 20 02:47:11 2009 UDPv4 link remote: 24.99.218.183:1194 Tue Jan 20 02:47:11 2009 read UDPv4 [ECONNREFUSED]: Connection refused (code=111) ( ^ this line repeats several hundred times ^ ) ... Tue Jan 20 03:03:51 2009 TLS Error: TLS key negotiation failed to occur within 999 seconds (check your network connectivity) Tue Jan 20 03:03:51 2009 TLS Error: TLS handshake failed Tue Jan 20 03:03:51 2009 TCP/UDP: Closing socket Tue Jan 20 03:03:51 2009 SIGUSR1[soft,tls-error] received, process restarting Tue Jan 20 03:03:51 2009 Restart pause, 2 second(s) Tue Jan 20 03:03:53 2009 IMPORTANT: OpenVPN's default port number is now 1194, based on an official port number assignment by IANA. OpenVPN 2.0-beta16 and earlier used 5000 as the default port. ...
Something is seriously wrong here...
Server Errors?
I did a `tail -f /var/log/*`, but wouldn't you know it: no server-side errors were generated. I searched the entire server for a some proprietary log dir/file for the OpenVPN daemon, but I found nothing.
So, I began to RTFM.
man openvpn
I did a search for "log" and found 3 relevant flags:
log- Specifies a log file and overwrites its current contents.
log-append- Specifies a log file and appends to its current contents.
daemon- Makes openvpn run as a daemon. Also, this makes openvpn log to syslog (ie: logs visible in /var/log/messages)
To see if any of these flags were specified and to what their values were, I checked the processes snapshot for the openvpn daemon.
# ps ax | grep open /usr/bin/openvpn --config /var/smoothwall/ovpn/server.red.conf
I checked the specified configuration file:
#OpenVPN red server conf config /var/smoothwall/ovpn/server.conf writepid /var/run/openvpn.rw.red.pid proto udp port 1194 dev tun0 server 10.68.214.0 255.255.255.0 push "route 192.168.0.0 255.255.255.0"
None of the 3 options are here, but another, more global configuration file is specified. Let's check it.
#OpenVPN common server conf daemon openvpnserver ;local guttersnipe.h1x.com tun-mtu 1400 tls-server ca /var/smoothwall/ovpn/ca/cacert.pem cert /var/smoothwall/ovpn/certs/servercert.pem key /var/smoothwall/ovpn/certs/serverkey.pem dh /var/smoothwall/ovpn/ca/dh1024.pem keepalive 10 60 status-version 1 status /var/smoothwall/ovpn/server.log 30 cipher BF-CBC max-clients 100 tls-verify "/var/smoothwall/ovpn/verify-cn /var/smoothwall/ovpn/ovpnconfig" crl-verify /var/smoothwall/ovpn/crls/cacrl.pem user nobody group nobody persist-key persist-tun verb 3
The above configuration file shows that, because the openvpn server's configuration file enables daemon mode without either log or log-append specified, the default Zerina openvpn server logs all errors to syslog. In the case of Smoothwall, this will put all error messages in the /var/log/messages file.
If I restart the OpenVPN server from the web interface (or even manually from the CLI), I can see said messages appear during a `tail -f /var/log/messages`.
Unfortunately, no errors appear when I try to connect. This means one of two things:
- There is an issue that occurs before the OpenVPN server--such as not being routed the connection attempt packets.
- OpenVPN receives the connection attempt and returns the ACK without an error, but an issue on my dorm's shitty double-NATed network is preventing the packets from being properly routed to my client.
tcpdump
At this point, there was very little information to go on. Without some sort of keywords (such as error messages) to search on, you're stuck. So, I got down as low as I could; I whipped out the packet sniffer.
I opened a tcpdump on both my smoothwall server and my client in the dorms.
I re-issued the openvpn client connection command, waited for a single "Connection refused" error message, and I immediately closed the openvpn client.
# openvpn guttersnipe-TO-SW.ovpn Tue Jan 20 04:08:33 2009 OpenVPN 2.1_rc7 x86_64-pc-linux-gnu [SSL] [LZO2] [EPOLL] built on Jun 11 2008 Tue Jan 20 04:08:33 2009 IMPORTANT: OpenVPN's default port number is now 1194, based on an official port number assignment by IANA. OpenVPN 2.0-beta16 and earlier used 5000 as the default port. Enter Private Key Password: Tue Jan 20 04:08:36 2009 WARNING: file 'guttersnipe.p12' is group or others accessible Tue Jan 20 04:08:36 2009 /usr/bin/openssl-vulnkey -q -b 1024 -m Tue Jan 20 04:08:37 2009 WARNING: normally if you use --mssfix and/or --fragment, you should also set --tun-mtu 1500 (currently it is 1400) Tue Jan 20 04:08:37 2009 Control Channel MTU parms [ L:1441 D:138 EF:38 EB:0 ET:0 EL:0 ] Tue Jan 20 04:08:37 2009 Data Channel MTU parms [ L:1441 D:1441 EF:41 EB:4 ET:0 EL:0 ] Tue Jan 20 04:08:37 2009 Local Options hash (VER=V4): '57657c3f' Tue Jan 20 04:08:37 2009 Expected Remote Options hash (VER=V4): '778eeec5' Tue Jan 20 04:08:37 2009 Socket Buffers: R=[122880->131072] S=[122880->131072] Tue Jan 20 04:08:37 2009 UDPv4 link local (bound): [undef]:1194 Tue Jan 20 04:08:37 2009 UDPv4 link remote: 24.99.218.183:1194 Tue Jan 20 04:08:37 2009 read UDPv4 [ECONNREFUSED]: Connection refused (code=111) Tue Jan 20 04:08:37 2009 event_wait : Interrupted system call (code=4) Tue Jan 20 04:08:37 2009 TCP/UDP: Closing socket Tue Jan 20 04:08:37 2009 SIGINT[hard,] received, process exiting
Sure enough, I instantly had two packets show up in each of my tcpdumps.
Note: You'll have to ignore the times on the packets; the date/time on the server and client are clearly out of sync.
OpenVPN Client
04:08:37.020585 00:1b:24:60:5e:ea (oui Unknown) > 00:01:f4:7f:17:d4 (oui Unknown), ethertype IPv4 (0x0800), length 56: (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto UDP (17), length 42) resnet-004-015.spsu.edu.openvpn > c-24-99-218-183.hsd1.ga.comcast.net.openvpn: UDP, length 14 E..*..@.@........c.........!8....N.K...... 04:08:37.028643 00:01:f4:7f:17:d4 (oui Unknown) > 00:1b:24:60:5e:ea (oui Unknown), ethertype IPv4 (0x0800), length 84: (tos 0x50, ttl 54, id 57156, offset 0, flags [none], proto ICMP (1), length 70) c-24-99-218-183.hsd1.ga.comcast.net > resnet-004-015.spsu.edu: ICMP c-24-99-218-183.hsd1.ga.comcast.net udp port openvpn unreachable, length 50 (tos 0x30, ttl 53, id 0, offset 0, flags [DF], proto UDP (17), length 42) resnet-004-015.spsu.edu.openvpn > c-24-99-218-183.hsd1.ga.comcast.net.openvpn: UDP, length 14 EP.F.D..6....c.........^....E0.*..@.5..Y.....c.........!8....N.K......
OpenVPN Server
04:07:16.540316 00:30:b8:c3:23:51 (oui Unknown) > 08:00:09:dd:8b:42 (oui Hewlett-Packard), ethertype IPv4 (0x0800), length 60: (tos 0x30, ttl 53, id 0, offset 0, flags [DF], proto UDP (17), length 42) 168.28.136.13.openvpn > c-24-99-218-183.hsd1.ga.comcast.net.openvpn: UDP, length 14
.c........X.8....N.K..........
04:07:16.540599 08:00:09:dd:8b:42 (oui Hewlett-Packard) > 00:30:b8:c3:23:51 (oui Unknown), ethertype IPv4 (0x0800), length 84: (tos 0xd0, ttl 64, id 57156, offset 0, flags [none], proto ICMP (1), length 70) c-24-99-218-183.hsd1.ga.comcast.net > 168.28.136.13: ICMP c-24-99-218-183.hsd1.ga.comcast.net udp port openvpn unreachable, length 50
(tos 0x30, ttl 53, id 0, offset 0, flags [DF], proto UDP (17), length 42) 168.28.136.13.openvpn > c-24-99-218-183.hsd1.ga.comcast.net.openvpn: UDP, length 14
.c........X.8....N.K......
The message here is a bit garbled, but here's the bottom-line: The client sent a packet to the server, and the server responded with another packet with the message of udp port openvpn unreachable.
I googled this message, and came across this page which said the following:
When you try to access a UDP port on a server, and nothing is listening for incoming UDP connections, the server should respond with an ICMP packet type 'UDP port unreachable'.
It seems the "udp port unreachable" is just a generic message for "there's nothing here to see." Since I received every packet that was sent from the server (one total), and it seemed to be a generic packet that probably didn't come from OpenVPN, it was clear that the issue wasn't with the client. The issue was with my home Smoothwall firewall.
nmap port scan
Just to make sure the ports were open, I ran a port scan on the openvpn port (1194).
# nmap -p1194 guttersnipe.h1x.com Starting Nmap 4.76 ( http://nmap.org ) at 2009-01-20 10:21 EST Interesting ports on c-24-99-218-183.hsd1.ga.comcast.net (24.99.218.183): PORT STATE SERVICE 1194/tcp filtered unknown Nmap done: 1 IP address (1 host up) scanned in 3.07 seconds
Filtered. Hmm; this doesn't look good.
iptables
If the port isn't open, it's likely to be a routing issue. Supposedly, Smoothwall and Zerina are supposed to handle this for you, but after this much troubleshooting, it began to be necessary to get down-and dirty. Thus, I took my first plunge ever into iptables.
Running iptables-save will display a 'backup' of the current iptables configuration. Here's the important bits that I found from my broken config:
# iptables-save ... -A INPUT -j REJECT --reject-with icmp-port-unreachable -A INPUT -i tun+ -j ACCEPT -A INPUT -i eth0 -p udp -m udp --dport 1194 -j ACCEPT ...
Resolution
I didn't get far outside of "a n00bs guide to iptables"-like documentation when I found the following from this great website:
Here's a dirty little secret: You never change iptables rules; you only add and delete them.
If we add this rule to our existing "stack" of rules, it won't work. Why not? Because the rules are applied in the order we added them...
...-A stands for append. New rules are added after existing ones... and our "REJECT all traffic" rule comes before the (newly added) rule. Simple as that. In order to get the rules to work the way we intended, we must also remove the "REJECT all traffic" rule and add it back so that it comes after the new ACCEPT rule.
This guide clearly outlined my issue: iptables rules are handled top-down. In my smoothwall firewall's configuration above, the "REJECT [all traffic]" rule is above the two openvpn rules. Thus, I received a "icmp port unreachable" rejection error.
iptables change
Issuing these commands will fix the above-described issue and properly open the openvpn port on the Smoothwall firewall for Zerina add-in.
cd /tmp iptables-save > 1 # backups are good iptables -D INPUT -j REJECT # delete the REJECT rule from the INPUT chain iptables-save > 2 iptables -A INPUT -j REJECT # re-add the REJECT rule to the end of the INPUT chain iptables-save > 3
Now iptables is configured like so:
# iptables-save ... -A INPUT -i tun+ -j ACCEPT -A INPUT -i eth0 -p udp -m udp --dport 1194 -j ACCEPT -A INPUT -j REJECT --reject-with icmp-port-unreachable ...
nmap rescan
To test it, I re-ran my port scan on the openvpn port (1194).
localhost ~ # nmap -p1194 guttersnipe.h1x.com Starting Nmap 4.76 ( http://nmap.org ) at 2009-01-20 13:14 EST Interesting ports on c-24-99-218-183.hsd1.ga.comcast.net (24.99.218.183): PORT STATE SERVICE 1194/tcp filtered unknown Nmap done: 1 IP address (1 host up) scanned in 1.65 seconds
It still says filtered. I'm not sure why it isn't open...
success!
Anyway, it doesn't matter; I re-ran my client's connection command, and--sure enough--everything worked as it should have 7 hours before.
# openvpn guttersnipe-TO-SW.ovpn Tue Jan 20 08:12:24 2009 OpenVPN 2.1_rc7 x86_64-pc-linux-gnu [SSL] [LZO2] [EPOLL] built on Jun 11 2008 Tue Jan 20 08:12:24 2009 IMPORTANT: OpenVPN's default port number is now 1194, based on an official port number assignment by IANA. OpenVPN 2.0-beta16 and earlier used 5000 as the default port. Enter Private Key Password: Tue Jan 20 08:12:27 2009 WARNING: file 'guttersnipe.p12' is group or others accessible Tue Jan 20 08:12:27 2009 /usr/bin/openssl-vulnkey -q -b 1024 -m Tue Jan 20 08:12:27 2009 WARNING: normally if you use --mssfix and/or --fragment, you should also set --tun-mtu 1500 (currently it is 1400) Tue Jan 20 08:12:27 2009 Control Channel MTU parms [ L:1441 D:138 EF:38 EB:0 ET:0 EL:0 ] Tue Jan 20 08:12:27 2009 Data Channel MTU parms [ L:1441 D:1441 EF:41 EB:4 ET:0 EL:0 ] Tue Jan 20 08:12:27 2009 Local Options hash (VER=V4): '57657c3f' Tue Jan 20 08:12:27 2009 Expected Remote Options hash (VER=V4): '778eeec5' Tue Jan 20 08:12:27 2009 Socket Buffers: R=[122880->131072] S=[122880->131072] Tue Jan 20 08:12:27 2009 UDPv4 link local (bound): [undef]:1194 Tue Jan 20 08:12:27 2009 UDPv4 link remote: 24.99.218.183:1194 Tue Jan 20 08:12:27 2009 TLS: Initial packet from 24.99.218.183:1194, sid=abbad444 b55ddcb7 Tue Jan 20 08:12:27 2009 VERIFY OK: depth=1, /C=US/O=The_Matrix/CN=The_Matrix_CA Tue Jan 20 08:12:27 2009 VERIFY OK: nsCertType=SERVER Tue Jan 20 08:12:27 2009 VERIFY OK: depth=0, /C=US/O=The_Matrix/CN=71.56.65.90 Tue Jan 20 08:12:28 2009 Data Channel Encrypt: Cipher 'BF-CBC' initialized with 128 bit key Tue Jan 20 08:12:28 2009 Data Channel Encrypt: Using 160 bit message hash 'SHA1' for HMAC authentication Tue Jan 20 08:12:28 2009 Data Channel Decrypt: Cipher 'BF-CBC' initialized with 128 bit key Tue Jan 20 08:12:28 2009 Data Channel Decrypt: Using 160 bit message hash 'SHA1' for HMAC authentication Tue Jan 20 08:12:28 2009 Control Channel: TLSv1, cipher TLSv1/SSLv3 DHE-RSA-AES256-SHA, 1024 bit RSA Tue Jan 20 08:12:28 2009 [71.56.65.90] Peer Connection Initiated with 24.99.218.183:1194 Tue Jan 20 08:12:29 2009 SENT CONTROL [71.56.65.90]: 'PUSH_REQUEST' (status=1) Tue Jan 20 08:12:29 2009 PUSH: Received control message: 'PUSH_REPLY,route 192.168.0.0 255.255.255.0,route 10.68.214.1,topology net30,ping 10,ping-restart 60,ifconfig 10.68.214.6 10.68.214.5' Tue Jan 20 08:12:29 2009 OPTIONS IMPORT: timers and/or timeouts modified Tue Jan 20 08:12:29 2009 OPTIONS IMPORT: --ifconfig/up options modified Tue Jan 20 08:12:29 2009 OPTIONS IMPORT: route options modified Tue Jan 20 08:12:29 2009 TUN/TAP device tun0 opened Tue Jan 20 08:12:29 2009 TUN/TAP TX queue length set to 100 Tue Jan 20 08:12:29 2009 ifconfig tun0 10.68.214.6 pointopoint 10.68.214.5 mtu 1400 Tue Jan 20 08:12:29 2009 route add -net 192.168.0.0 netmask 255.255.255.0 gw 10.68.214.5 Tue Jan 20 08:12:29 2009 route add -net 10.68.214.1 netmask 255.255.255.255 gw 10.68.214.5 Tue Jan 20 08:12:29 2009 Initialization Sequence Completed
Beautiful.
More Fixin'
I finally connected OK, but I could still only access my smoothwall server. I couldn't communicate with any of the other computers on my home network or the internet.
Thankfully, the lovely OpenVPN FAQs outlined How to xpand the scope of the VPN to include additional machines on either the client or server subnet --exactly what I needed.
Once the VPN is operational in a point-to-point capacity between client and server, it may be desirable to expand the scope of the VPN so that clients can reach multiple machines on the server network, rather than only the server machine itself.
For the purpose of this example, we will assume that the server-side LAN uses a subnet of 10.66.0.0/24 and the VPN IP address pool uses 10.8.0.0/24 as cited in the server directive in the OpenVPN server configuration file.
First, you must advertise the 10.66.0.0/24 subnet to VPN clients as being accessible through the VPN. This can easily be done with the following server-side config file directive:
I checked the current route configuration. By default, everything looks good.
#route Kernel IP routing table Destination Gateway Genmask Flags Metric Ref Use Iface 10.68.214.2 * 255.255.255.255 UH 0 0 0 tun0 10.68.214.0 10.68.214.2 255.255.255.0 UG 0 0 0 tun0 ...
Continuing...
Next, you must set up a route on the server-side LAN gateway to route the VPN client subnet (10.8.0.0/24) to the OpenVPN server (this is only necessary if the OpenVPN server and the LAN gateway are different machines).
Make sure that you've enabled IP and TUN/TAP forwarding on the OpenVPN server machine.
The article links to another FAQ for Enabling IP and TUN forwarding on the OpenVPN server machine
My OpenVPN client and server say "Connection Initiated with x.x.x.x" but I cannot ping the server through the VPN. Why?
This usually occurs because a firewall on the server or client is blocking the TUN/TAP interface. If you already have a firewall on your system, chances are high that it will block incoming connections on new interfaces by default, so you will need to add explicit firewall rules to allow connections via the TUN/TAP interface. In general, it's reasonable to open up TUN/TAP interfaces to all traffic, since any incoming connections over these interfaces will already have been authenticated by OpenVPN. An exception to this rule would be if you don't fully trust the OpenVPN clients connecting to the server. Assuming that's not the case, on Linux, TUN/TAP interfaces can be opened up with the iptables shell command:
#Allow TUN interface connections to OpenVPN server
iptables -A INPUT -i tun+ -j ACCEPT#Allow TUN interface connections to be forwarded through other interfaces
iptables -A FORWARD -i tun+ -j ACCEPT
The only problem with this guide as it relates to the Smoothwall firewall is that, like the earlier issue, there is a "REJECT [all traffic]" at the end of the FORWARD and INPUT chains. If you append the rule as suggested, it will be added after the "REJECT [all traffic]" rule, and it won't work.
Running these commands will enable TUN forwarding on a Smoothwall server so that a client "Road Runner" connected to the Smoothwall's Zerina addin's OpenVPN server implementation can access
- All the machines behind your Smoothwall server, and
- The Internet
through your OpenVPN tunnel.
cd /tmp iptables-save > 4 # backups are good iptables -D INPUT -j REJECT # delete the REJECT rule from the INPUT chain iptables-save > 5 iptables -D FORWARD -j REJECT # delete the REJECT rule from the FORWARD chain iptables-save > 6 # Allow TUN interface connections to OpenVPN server iptables -A INPUT -i tun+ -j ACCEPT iptables-save > 7 # Allow TUN interface connections to be forwarded through other interfaces iptables -A FORWARD -i tun+ -j ACCEPT iptables-save > 8 iptables -A INPUT -j REJECT # re-add the REJECT rule to the end of the INPUT chain iptables-save > 9 iptables -A FORWARD -j REJECT # re-add the REJECT rule to the end of the FORWARD chain iptables-save 10
Everything should now work.
Conclusion
My OpenVPN was working fine before. I know that recent updates to the Smoothwall box have something to do with the breaking of Zerina, but I'm not sure why. I even tried reinstalling Zerina, but to no avail.
I said before that I was quite impressed with Zerina, but I'm not so sure now. If one is so inclined, you can fix these forwards that are supposed to be setup automatically, but the reason you use such add-ins is for just the opposite: ease.
-20 points for Zerina, I'm afraid. Then again, it's really only tested for IPCop...
Testing the tunnel
Just to witness the awesomeness of encryption, here's a client-side tcpdump when
- Accessing google in firefox normally, and
- Accessing google in firefox through the VPN
Note: I disabled gzip compression in firefox to make this example clearer.
Normal (unencrypted)
tcpdump: listening on eth0, link-type EN10MB (Ethernet), capture size 65535 bytes
09:50:45.740750 00:01:f4:7f:17:d4 (oui Unknown) > 00:1b:24:60:5e:ea (oui Unknown), ethertype IPv4 (0x0800), length 74: (tos 0x30, ttl 56, id 61985, offset 0, flags [none], proto TCP (6), length 60) yw-in-f104.google.com.www > resnet-004-015.spsu.edu.56928: S, cksum 0xeffe (correct), 2569391291:2569391291(0) ack 3610699216 win 5672
E0. 00:1b:24:60:5e:ea (oui Unknown), ethertype IPv4 (0x0800), length 198: (tos 0x0, ttl 61, id 0, offset 0, flags [DF], proto UDP (17), length 184) einstein.SPSU.edu.domain > resnet-004-015.spsu.edu.54877: 51912* 1/2/2 15.4.16.172.in-addr.arpa. PTR resnet-004-015.spsu.edu. (156)
E.....@.=.4..........5.]..X..............15.4.16.172.in-addr.arpa..............X...resnet-004-015.spsu.edu.........Q....einstein.E........Q..
.ns1.usg.J.r.......-...HH
.[.......X......
09:50:45.744369 00:01:f4:7f:17:d4 (oui Unknown) > 00:1b:24:60:5e:ea (oui Unknown), ethertype IPv4 (0x0800), length 193: (tos 0x0, ttl 61, id 0, offset 0, flags [DF], proto UDP (17), length 179) einstein.SPSU.edu.domain > resnet-004-015.spsu.edu.52206: 34418 1/4/0 104.47.125.74.in-addr.arpa. PTR yw-in-f104.google.com. (151)
E.....@.=.4..........5....5..r...........104.47.125.74.in-addr.arpa.............Po..
yw-in-f104.google.com.........P ...ns3.C........P ...ns4.C........P ...ns1.C........P ...ns2.C
09:50:45.745460 00:01:f4:7f:17:d4 (oui Unknown) > 00:1b:24:60:5e:ea (oui Unknown), ethertype IPv4 (0x0800), length 185: (tos 0x0, ttl 61, id 0, offset 0, flags [DF], proto UDP (17), length 171) einstein.SPSU.edu.domain > resnet-004-015.spsu.edu.36423: 816* 1/2/2 11.176.28.168.in-addr.arpa. PTR einstein.SPSU.edu. (143)
E.....@.=.4..........5.G..m..0...........11.176.28.168.in-addr.arpa..............X...einstein.SPSU.edu.........Q..
.ns1.usg.F........Q....8.W.......-...HH
.8.......X......
09:50:45.746490 00:01:f4:7f:17:d4 (oui Unknown) > 00:1b:24:60:5e:ea (oui Unknown), ethertype IPv4 (0x0800), length 66: (tos 0x30, ttl 56, id 61986, offset 0, flags [none], proto TCP (6), length 52) yw-in-f104.google.com.www > resnet-004-015.spsu.edu.56928: ., cksum 0x3211 (correct), ack 592 win 108
E0.4."..8.fmJ}/h.....P.`.%...6.....l2......
.I...tE.
09:50:45.753179 00:01:f4:7f:17:d4 (oui Unknown) > 00:1b:24:60:5e:ea (oui Unknown), ethertype IPv4 (0x0800), length 1484: (tos 0x30, ttl 56, id 61987, offset 0, flags [none], proto TCP (6), length 1470) yw-in-f104.google.com.www > resnet-004-015.spsu.edu.56928: ., cksum 0xe2c5 (correct), 1:1419(1418) ack 592 win 108
E0...#..8.`.J}/h.....P.`.%...6.....l.......
.I...tE.HTTP/1.1 200 OK
Cache-Control: private, max-age=0
Date: Tue, 20 Jan 2009 14:50:43 GMT
Expires: -1
Content-Type: text/html; charset=UTF-8
Server: gws
Transfer-Encoding: chunked
17a8
Googlebody,td,a,p,.h{font-family:arial,sans-serif}.h{color:#36c}.q{color:#00c}.ts td{padding:0}.ts{border-collapse:collapse}#gbar{height:22px;padding-left:2px}.gbh,.gbd{border-top:1px solid #c9d7f1;font-size:1px}.gbh{height:0;position:absolute;top:24px;width:100%}#gbi,#gbs{background:#fff;left:0;position:absolute;top:24px;visibility:hidden;z-index:1000}#gbi{border:1px solid;border-color:#c9d7f1 #36c #36c #a2bae7;z-index:1001}#guser{padding-bottom:7px !important}#gbar,#guser{font-size:13px;padding-top:1px !important}@media all{.gb1,.gb3{height:22px;margin-right:.73em;vertical-align:top}#gbar{float:left}}.gb2{display:block;padding:.2em .5em}a.gb1,a.gb2,a.gb3{color:#00c !important}.gb2,.gb3{text-decoration:none}a.gb2:hover{background:#36c;color:#fff !important}window.google={kEI:"w-R1SdD9AYzw8ATuoY2NCQ",kEXPI:"17259,17291",kHL:"en"};
google.y={};google.x=function(e,g){google.y[e.id]=[e,g];return false};window.clk=function(b,c,d,e,f,g){if(document.images){var a=encodeURIComponent||escape;(new Image).src="/url?sa=T"+(c?"&oi="+a(c):"")+(d?"&cad="+a(d):"")+"&ct="+a(e)+"&cd="+a(f)+(b?"&url="+a(b.repla
09:50:45.753291 00:01:f4:7f:17:d4 (oui Unknown) > 00:1b:24:60:5e:ea (oui Unknown), ethertype IPv4 (0x0800), length 1484: (tos 0x30, ttl 56, id 61988, offset 0, flags [none], proto TCP (6), length 1470) yw-in-f104.google.com.www > resnet-004-015.spsu.edu.56928: ., cksum 0xe591 (correct), 1419:2837(1418) ack 592 win 108
E0...$..8.`.J}/h.....P.`.%.F.6.....l.......
.I...tE.ce(/#.*/,"")).replace(/+/g,"%2B"):"")+"&ei=w-R1SdD9AYzw8ATuoY2NCQ"+g}return true};
window.gbar={};(function(){var b=window.gbar,f,h;b.qs=function(a){var c=window.encodeURIComponent&&(document.forms[0].q||"").value;if(c)a.href=a.href.replace(/([?&])q=[^&]*|$/,function(i,g){return(g||"&")+"q="+encodeURIComponent(c)})};function j(a,c){a.visibility=h?"hidden":"visible";a.left=c+"px"}b.tg=function(a){a=a||window.event;var c=0,i,g=window.navExtra,d=document.getElementById("gbi"),e=a.target||a.srcElement;a.cancelBubble=true;if(!f){f=document.createElement(Array.every||window.createPopup?"iframe":"div");f.frameBorder="0";f.src="#";d.parentNode.appendChild(f).id="gbs";if(g)for(i in g)d.insertBefore(g[i],d.firstChild).className="gb2";document.onclick=b.close}if(e.className!="gb3")e=e.parentNode;do c+=e.offsetLeft;while(e=e.offsetParent);j(d.style,c);f.style.width=d.offsetWidth+"px";f.style.height=d.offsetHeight+"px";j(f.style,c);h=!h};b.close=function(a){h&&b.tg(a)}})();Web Images Maps 00:1b:24:60:5e:ea (oui Unknown), ethertype IPv4 (0x0800), length 493: (tos 0x30, ttl 56, id 61989, offset 0, flags [none], proto TCP (6), length 479) yw-in-f104.google.com.www > resnet-004-015.spsu.edu.56928: P, cksum 0xddb7 (correct), 2837:3264(427) ack 592 win 108
E0...%..8.d.J}/h.....P.`.%...6.....l.......
.I...tE.ef="http://news.google.com/nwshp?hl=en&tab=wn" onclick=gbar.qs(this) class=gb1>News Shopping Gmail more ▼ Video Groups Books Scholar Finance Blogs YouTube Calendar Photos Documents Reader Sites even more » iGoogle | Sign in
Advanced Search
Preferences
Language Tools
Advertising Programs - Business Solutions - About Google©2009 - Privacyif(google.y)google.y.first=[];window.setTimeout(function(){var xjs=document.createElement('script');xjs.src='/extern_js/f/CgJlbhICdXMrMAo4DSwrMA44BCwrMBg4Ayw/1SnTlIZln00.js';docum
09:50:45.757188 00:01:f4:7f:17:d4 (oui Unknown) > 00:1b:24:60:5e:ea (oui Unknown), ethertype IPv4 (0x0800), length 221: (tos 0x30, ttl 56, id 61992, offset 0, flags [none], proto TCP (6), length 207) yw-in-f104.google.com.www > resnet-004-015.spsu.edu.56928: P, cksum 0x36f8 (correct), 6100:6255(155) ack 592 win 108
E0...(..8.e.J}/h.....P.`.%...6.....l6......
.I...tE.ent.getElementsByTagName('head')[0].appendChild(xjs)},0);google.y.first.push(function(){google.ac.i(document.f,document.f.q,'','')})
0
09:50:45.961800 00:01:f4:7f:17:d4 (oui Unknown) > 00:1b:24:60:5e:ea (oui Unknown), ethertype IPv4 (0x0800), length 74: (tos 0x30, ttl 56, id 37416, offset 0, flags [none], proto TCP (6), length 60) eo-in-f102.google.com.www > resnet-004-015.spsu.edu.40353: S, cksum 0x6c5c (correct), 1057868803:1057868803(0) ack 3624839158 win 5672
.........(l.........P..?
Xc...tE.....
09:50:45.962721 00:01:f4:7f:17:d4 (oui Unknown) > 00:1b:24:60:5e:ea (oui Unknown), ethertype IPv4 (0x0800), length 194: (tos 0x0, ttl 61, id 0, offset 0, flags [DF], proto UDP (17), length 180) einstein.SPSU.edu.domain > resnet-004-015.spsu.edu.57472: 52674 1/4/0 102.165.85.209.in-addr.arpa. PTR eo-in-f102.google.com. (152)
E.....@.=.4..........5.....y.............102.165.85.209.in-addr.arpa.............QZ..
eo-in-f102.google.com.........QZ...ns2.D........QZ...ns3.D........QZ...ns4.D........QZ...ns1.D
09:50:45.966115 00:01:f4:7f:17:d4 (oui Unknown) > 00:1b:24:60:5e:ea (oui Unknown), ethertype IPv4 (0x0800), length 66: (tos 0x30, ttl 56, id 37417, offset 0, flags [none], proto TCP (6), length 52) eo-in-f102.google.com.www > resnet-004-015.spsu.edu.40353: ., cksum 0xae5b (correct), ack 612 win 108
.....Y...l.[.........P..?
Xc...tE.
09:50:45.966938 00:01:f4:7f:17:d4 (oui Unknown) > 00:1b:24:60:5e:ea (oui Unknown), ethertype IPv4 (0x0800), length 191: (tos 0x30, ttl 56, id 37418, offset 0, flags [none], proto TCP (6), length 177) eo-in-f102.google.com.www > resnet-004-015.spsu.edu.40353: P, cksum 0x445c (correct), 1:126(125) ack 612 win 108
.....Y...lD.........P..?
Xc...tE.HTTP/1.1 204 No Content
Date: Tue, 20 Jan 2009 14:50:43 GMT
Content-Type: text/html
Server: GFE/1.3
Content-Length: 0
It mostly looks garbled, but if you stare at it, you can see all of the Headers/HTML/CSS/etc data in cleartext.
VPN (encrypted)
tcpdump: listening on eth0, link-type EN10MB (Ethernet), capture size 65535 bytes
10:00:28.085057 00:01:f4:7f:17:d4 (oui Unknown) > 00:1b:24:60:5e:ea (oui Unknown), ethertype IPv4 (0x0800), length 143: (tos 0x50, ttl 54, id 0, offset 0, flags [DF], proto UDP (17), length 129) c-24-99-218-183.hsd1.ga.comcast.net.openvpn > trinity.local.openvpn: UDP, length 101
EP....@.6....c...........mF.0.c.,..../x....._{.Er......&.o....2.zi..c......... <....Y.....p... 00:1b:24:60:5e:ea (oui Unknown), ethertype IPv4 (0x0800), length 151: (tos 0x50, ttl 54, id 0, offset 0, flags [DF], proto UDP (17), length 137) c-24-99-218-183.hsd1.ga.comcast.net.openvpn > trinity.local.openvpn: UDP, length 109
.Z*b.........;%Ne.!.......U"0.z.;pS.w./....2.4l.T(.^U..V..R5...DgR
J..B1....cj....
10:00:28.234201 00:01:f4:7f:17:d4 (oui Unknown) > 00:1b:24:60:5e:ea (oui Unknown), ethertype IPv4 (0x0800), length 199: (tos 0x50, ttl 54, id 0, offset 0, flags [DF], proto UDP (17), length 185) c-24-99-218-183.hsd1.ga.comcast.net.openvpn > trinity.local.openvpn: UDP, length 157
EP....@.6....c..............0ur......N[.5.MSm.3#MJ.W..6..-...M..Rb.a.....S38.ecW.....a...6tT.H.9..:=a... ..[u0..ZH_....v........8...@................L-.;............4?`X....C.U..S.r.+.Y
10:00:28.271401 00:01:f4:7f:17:d4 (oui Unknown) > 00:1b:24:60:5e:ea (oui Unknown), ethertype IPv4 (0x0800), length 135: (tos 0x50, ttl 54, id 0, offset 0, flags [DF], proto UDP (17), length 121) c-24-99-218-183.hsd1.ga.comcast.net.openvpn > trinity.local.openvpn: UDP, length 93
EP.y..@.6....c...........e.$0......I.p.......#..0.s....?T......k&.$....
...........W...@.i.
./..G.6..W.y.e.[.}.u...
10:00:28.319730 00:01:f4:7f:17:d4 (oui Unknown) > 00:1b:24:60:5e:ea (oui Unknown), ethertype IPv4 (0x0800), length 1479: (tos 0x50, ttl 54, id 0, offset 0, flags [DF], proto UDP (17), length 1465) c-24-99-218-183.hsd1.ga.comcast.net.openvpn > trinity.local.openvpn: UDP, length 1437
./U....W....){.r...+.S...1.h..Le.J.,........4%}.]bS.u...g..pd.o..N..X{...q...9...*.)...(.,.DH...^}Dd..l...1z0.......W...R......K>L+..]_.{....vu...6..........^X._|.y.@..:BZ...9.s.......(k.....u.G,q.uOs..Oo.}.:+".L.. T..(mhk.*"......x.R..J8.O.....JV..@..+.,.+Y5.y.A..[Zo.]&+..6;#...>....o..=.j.....mU....xY.n.f.>U&.H.;AC....N=..wX..FO|......`_".......o].....4..Z<.hu..:...V......`[.S...Ts..d..A.............x.cc9.........h}...koR.[';......=...r..l.$.T..pl...s....E(..q^...ON....kK...5.dKk...C$......Bpw.|.;..X..Jy...&..........MC.4.3..wmbx.^..n..$.aK..l.!.D. ..,.$..av..EH._.(.6.cQ.C.....2#.yE.9q#}L[...]u.x.c... ..$E....9.>j.p.>.5?..'..y.W.p.)..l:.o.)m.:..4.=....hX,9}zEd.e.9...q.;.....9.!.lS.Q.SK.f.((...D3...Uzc..t.%.9QD.H..^.......f......ZYO" 7.;y...8...d!..".c.H;... 00:1b:24:60:5e:ea (oui Unknown), ethertype IPv4 (0x0800), length 247: (tos 0x50, ttl 54, id 0, offset 0, flags [DF], proto UDP (17), length 233) c-24-99-218-183.hsd1.ga.comcast.net.openvpn > trinity.local.openvpn: UDP, length 205
EP....@.6..z.c..............0^4i..n.wv..I.@..zo.q.B.bN.....(.......A..{.F.W...w[..h.=.o>.D..d..
^J....|..`U...1....OC.>...%D..DRG{..b..9H.._..r..84U.......`9....[-$FM......S...5J.........v].4.!z...m!.....e...].t.L(...K.V....
10:00:28.410881 00:01:f4:7f:17:d4 (oui Unknown) > 00:1b:24:60:5e:ea (oui Unknown), ethertype IPv4 (0x0800), length 1479: (tos 0x50, ttl 54, id 0, offset 0, flags [DF], proto UDP (17), length 1465) c-24-99-218-183.hsd1.ga.comcast.net.openvpn > trinity.local.openvpn: UDP, length 1437
....iX...%.......%.t.Z..../.x.q..{..P.....cJ_j......4..Y.".K.B..t;M.9.c.........~.I.8..[....).>.....'..@..&..7. ..mZ.d..;..0v9].o./..n]EC.S.0..Z....0.....n......F1 e.v.@.?......y....n...yQd..b...#...Q..v..6..o.f...o&,~v....... 1..6]n._....8s.>B.%.).......f....0.LYy..L...k.....
..KL....D'..l.(.R.......|........MO..PX+g..eR..{.q"...Igjh..;l.........&..xe.E^..1..k.%!....d,..9B...a...Y...v......V..d..I.?D..Oo.. }"#z~..J.Q.b..O..t..#.6(.d...iT..j.....~......{U......"..~P..<..d...n5P#]Qj...s..S..F_.K..(7.....LN.Y8.;..,.Q......v.J...:..S..@....u8.Us[....P....tz..Z....8.v'..A....d.....`P~.Gc...._..ps$.....[.f.E.I...<z..s.....7.~...%V........)M...sm.E....@..<d.....-A".)..'.7rn.E.....r..E...H.....*-.y.1.J. ....G...D....b.......].2.................9`.....k...5 C.M.(........-G&)N.D..L.P.}._E.r...~......j..bK@.&.4:=C.X.....". .t..
.....a.J.Z.WV......O../..A'.....%~..r..J.[......p'.F.a.../1.....6}.,=M..w.d....+...E.='..s E..q4.b...f%Rse..]..{ ......L(..&.^.^.Y.:GQL.R......S...
[*)..
[.M..$...v....wr_f....(......S...RwG..L...RZ...Mq..L......5...7......t.V=..o..,....../.Q.......i......u..v...v.z8.....0..pE..e*by3..$K.NE*0K:k.cY,......... $].5F.1....7....7.....Y."~.x^.t...Z...yj.....4 ].7.....*G8..4...9g....[.h...P.z..
tf.!P...+.....+..8.Xf...@.|0
10:00:28.415293 00:01:f4:7f:17:d4 (oui Unknown) > 00:1b:24:60:5e:ea (oui Unknown), ethertype IPv4 (0x0800), length 1479: (tos 0x50, ttl 54, id 0, offset 0, flags [DF], proto UDP (17), length 1465) c-24-99-218-183.hsd1.ga.comcast.net.openvpn > trinity.local.openvpn: UDP, length 1437
EP....@.6....c..............0...O..Ju.]*"..(.........v.-.R...x.P...?...J_o..].f..h`.r.Sf.a...8_.;..X9q..QR&.....5}SO....V.Z...&A.&..]r+.m..Pw..).l......RZA..q./.".W.J....y...e....h...G......P.L]e...f.........!..0q...X.27..........x.7..4S...0l].:,.;q.4..B...,y.B....V ....Wt|.Z.i........D..A.......P..!.I.?&.|.9.*.m.`.}..{..QY..KE=.{...p.M]....c(.M...TS.(..|.X>.2..k.`...AFi.^.9:....c.^..bz..Q.G.a......X..&5....7 (....0.&..^..r.w.A.....meD..).v.
.E..... .^.L.C...p..&......T..%......Ch.....J.f..:{{N24....>...Qu.g..g^?..O.o.....k5.........-...K....[..........`...~l*...1..O.I|5.9...1....v......2d..J..d.......s.N...2...}.
.d.v.t....[i..(...? .`.D:.n....o3.r. V.V....d
'!M../.'.e.a..R.....* ...l..h....G...n...C..-zE...S|..7.v->1cP.S...p#....2>................G.3".".$.8.S...KK.L..U.....z.:G.}y..&..}....7....ji&?C).........^.qc..T..Q>.....}..,.H.....y=..W.A+.k7.{....x......w....Q.Ar3.R....5.+7cXF.#....YG.."g..5..$i.&.Yy..t..........d...1.8S
9.....k.....Z..*n1t...(..Z..._q= .W..K..o.....{.~8..9.9.E,.7..Yv....p.....J.%......+ ...O..VvX1>.!cLq..x7......&W.R.F.L...S.].z...AM..|...#p.n..Y.J|..L.a.H"..
10:00:28.436086 00:01:f4:7f:17:d4 (oui Unknown) > 00:1b:24:60:5e:ea (oui Unknown), ethertype IPv4 (0x0800), length 1479: (tos 0x50, ttl 54, id 0, offset 0, flags [DF], proto UDP (17), length 1465) c-24-99-218-183.hsd1.ga.comcast.net.openvpn > trinity.local.openvpn: UDP, length 1437
EP....@.6....c..............0...ii;.o.00y..V..J.W..gsu.v^...X>.R}e#..e.../.y...=&.1C.4?.....r.....w..Z KL....;...;..9..J...0....,w 0k?.W.RV...D....BR.....s.n+.>
....-q1~0.q ...h/.8....nA..... _.`.#.tC.I.B.1...{..../.8=ev..~H.a......./...M.cf.dw'...Q.-W.w.g.......x.AX.6.)x............c_.j..<...|.H+Q..M.5a...F.u.YJ.......P......k......a......2.xJ..w..V%.N@.n.....J......)..... &)ar.@.z...l.c^M.Ou.Q...T..+K[....T.:+.r.;-....g...".........b)*....q..7 .!..h..._.....k..OB.]L).9....[..X......zK....6.%....Q....g.....w.*q........-&.~....i.].8i...(.DA.$W.F=.. ...W..6@.....S.b..1.(.+.....0..y/0..A.#..p}.........a*I...4<...i...EL..P...y94RA0[|<TA.Y..E.4..dn.....t%.E..t.....[.z.c.....T.!&.5()...D."..M.. .....!;,C.k.~.....j.n.....$..YN7...x..sl.}....5c.......$;.og....v....}.3...M'.nH......n.U..a%..N..;@|...?..Ao2.....EUj.azk._y.d....Z&.v.k%.A..U..>s.K..Jw..k.O.So.D......]uM..Fc3..]... ..Fn.S.c.J..8!n........J.'.c.P..J..h.6..Mj.-.{9 4..x....q,..eI_..$...q..).Y..f........g.C.......Q..L..Q..O .0i.?8r.Xb........4&...plp...>..e.+.N.-_.Y..P......r...~.U...`.).4.e;..3.&.0`....$X*
10:00:28.447584 00:01:f4:7f:17:d4 (oui Unknown) > 00:1b:24:60:5e:ea (oui Unknown), ethertype IPv4 (0x0800), length 895: (tos 0x50, ttl 54, id 0, offset 0, flags [DF], proto UDP (17), length 881) c-24-99-218-183.hsd1.ga.comcast.net.openvpn > trinity.local.openvpn: UDP, length 853
..."Sd..'....,.B.|.D2.f}.24...}>.+)T....|."....}..L.36.....C.kr..x-........J..g..|....T....sX........./[.Q&....
.. W{d).&/8..}_....#..]?..-..4"*.[Va...u..l...-~$R:...A1.hko@..^.b."Dv.wk....>A...!....GO. .'.........g;....kW..|.D.3-I....1....ki?ISg(.d.mo..1.(g......9i......v..-.-`j$.Z....{#... .23...eb..1{....Xa]. ..U....
10:00:28.529029 00:01:f4:7f:17:d4 (oui Unknown) > 00:1b:24:60:5e:ea (oui Unknown), ethertype IPv4 (0x0800), length 135: (tos 0x50, ttl 54, id 0, offset 0, flags [DF], proto UDP (17), length 121) c-24-99-218-183.hsd1.ga.comcast.net.openvpn > trinity.local.openvpn: UDP, length 93
EP.y..@.6....c...........e.%0M.......Y.(..}V.$..;.VU.{.|...z].T|..9)L..3fE....|C...2....2'...98..|.s.s.s.....~].....XR.d.
10:00:28.766257 00:01:f4:7f:17:d4 (oui Unknown) > 00:1b:24:60:5e:ea (oui Unknown), ethertype IPv4 (0x0800), length 143: (tos 0x50, ttl 54, id 0, offset 0, flags [DF], proto UDP (17), length 129) c-24-99-218-183.hsd1.ga.comcast.net.openvpn > trinity.local.openvpn: UDP, length 101
EP....@.6....c...........mg.0.....j..k T5(.T..Fj...>NL..X..$..R.51....>.....,.....%........a..X..i-.m....("V.....Fkl..q.G.....3..
10:00:28.951875 00:01:f4:7f:17:d4 (oui Unknown) > 00:1b:24:60:5e:ea (oui Unknown), ethertype IPv4 (0x0800), length 135: (tos 0x50, ttl 54, id 0, offset 0, flags [DF], proto UDP (17), length 121) c-24-99-218-183.hsd1.ga.comcast.net.openvpn > trinity.local.openvpn: UDP, length 93
}..m.3.V/..W.o,{@q...R.R~|.....V..roc.%5.*.tN.......L....np..P...}n,v.C>Wdv.}40#.
10:00:28.957117 00:01:f4:7f:17:d4 (oui Unknown) > 00:1b:24:60:5e:ea (oui Unknown), ethertype IPv4 (0x0800), length 255: (tos 0x50, ttl 54, id 0, offset 0, flags [DF], proto UDP (17), length 241) c-24-99-218-183.hsd1.ga.comcast.net.openvpn > trinity.local.openvpn: UDP, length 213
EP....@.6..r.c............A.0.~.......!..18.R..F...0..K....@u.....y... ..l.......R
...G....#.[.R.2o.... >...T...}~...5.N..#lRM..... ...iY....d+..h.l...g[..vl..9&B..q.R.
14 packets captured
14 packets received by filter
0 packets dropped by kernel
This time, no logical data is visible. The only 'risky' thing an attacker gets is my OpenVPN Internet IP Address.
I <3 security.
Other Notes
It's been brought to my attention that this is way too complicated for my needs. Apparently a simple ssh command can also open an encrypted tunnel in the same way. Moreover, you can have all your applications go through a global SOCKS proxy created by this tunnel to ensure everything gets encrypted. *shrug*
Related Posts
Hi, I’m Michael Altfield. I write articles about opsec, privacy, and devops ➡
Also, I get 4x the download speed on the school's wireless when I'm running through my openvpn tunnel.
Take that packet shapers!