Fun with OpenSolaris and OpenVPN
Since it seems that my new neighbors run an unsecured wireless network (not that I’m one to talk, as I certainly don’t bother encrypting mine), I though I’d hop on. With names (I’m assuming by the same person) like Tubgirl.org and 2girls1cup I was a bit leery about them redirecting all my traffic, but it wasn’t to be the case. I have no problems doing anything, but I’m suspecting they ran an unsecured SMTP server which was used as a spam relay at some point. Port 25 is blocked. SSH port forwarding is apparently too complicated for Heather in the few times she can actually get on the networks (chalk that up to shitty transmission power and network code from Windows, since we have virtually identical laptops and I’ve got no issues in Solaris or OSX), so she can’t send anything.
I figured I’d set up a VPN server on the connection I still have at Steph’s house until such time as we actually get cable installed. I can’t do it myself, since I still have an account open with them. I could transfer the service, but then I wouldn’t get all the new subscriber deals, so…
Solaris doesn’t come with device nodes for tunneling IP connections (other than IPSEC, which I’m not going to set up due to the complexity involved for a short-term solution). It does have device nodes and drivers for bridging, but they’re kind of limited when it comes to pinging the host that initiated the tunnel from the client. A virtual ethernet adapter would get around that, but it’d be needlessly hacky.
For whatever reason, the tun/tap drivers didn’t want to compile. Well, it’s not “whatever reason.” It’s “developer doesn’t bother to check whether or not Solaris systems are 64 bit since he only gives a fuck about Linux.” Easy fix in the Makefile:
CFLAGS = $(DEFS) -O2 -Wall -D_KERNEL -I. -m64 -mcmodel=kernel -mno-red-zone
After compiling, more problems. The device didn’t want to attach. Kernel drivers for 64 bit x86 don’t go in /platform/i86pc/kernel/drv/amd64, they go in /usr/kernel/drv/amd64. Fixed and loaded. On to OpenVPN:
Compile and install. Generate SSL certificates, sign keys for VPN clients. Set up configuration:
local 192.168.0.8
port 443 #nobody's going to block outgoing HTTPS, and I'll never run an HTTPS server at home
proto udp
dev tun #L2 routing, not ethernet bridging. Clients don't need broadcast.
ca ca.crt
cert alucard.crt
key alucard.key
dh dh1024.pem #more encryption
server 10.8.0.0 255.255.255.0
ifconfig-pool-persist ipp.txt #DHCP for the VPN
push "route 192.168.0.0 255.255.255.0" #routes to get to the rest of my networks
push "route 10.0.0.0 255.255.0.0"
push "redirect-gateway" #all traffic over the tunnel
push "dhcp-option DNS 192.168.0.1" #Windows needs this
push "dhcp-option WINS 192.168.0.2" #Also Windows
client-to-client #let clients see each other
keepalive 10 120 #send pings to keep the connection alive
tls-auth ta.key 0 #helps revent DoS
cipher BF-CBC #use Blowfish encryption
comp-lzo #compression
user nobody
group nobody #take away server priviledges
persist-key
persist-tun #keep keys and tunnels even after priviledge is disabled
status openvpn-status.log
log-append openvpn.log #don't overwrite logs on restart
verb 6 #verbosity for the log to diagnose connection problems
mute 20 #don't repeat more than 20 sequential messages in the log
Routes are set to let them see my network at home, but network clients need to know how to get back to them:
root@OpenWrt:~$ route add -net 10.8.0.0 netmask 255.255.255.0 gw 192.168.0.8
root@OpenWrt:~$ route
Kernel IP routing table
Destination Gateway Genmask Flags Metric Ref Use Iface
10.8.0.0 192.168.0.8 255.255.255.0 UG 0 0 0 br0
10.0.0.0 192.168.0.8 255.255.0.0 UG 0 0 0 br0
192.168.0.0 * 255.255.255.0 U 0 0 0 br0
24.118.228.0 * 255.255.254.0 U 0 0 0 vlan1
default c-3-0-ubr04.eag 0.0.0.0 UG 0 0 0 vlan1
default 192.168.0.1 0.0.0.0 UG 0 0 0 br0
root@OpenWrt:~$
Good so far. NAT would be a good thing, though. They can all appear to come from my server. Turning on the firewall?
Configuration:
alucard[/]# cat /etc/ipf/ipnat.conf
map bge0 10.8.0.0/24 -> 0/32 portmap tcp/udp auto
map bge0 10.8.0.0/24 -> 0/32
alucard[/]#ipnat -f /etc/ipf/ipnat.conf
alucard[/]# ipnat -l
List of active MAP/Redirect filters:
map bge0 10.8.0.0/24 -> 0.0.0.0/32 portmap tcp/udp auto #change source port to random between 10000 and 20000
map bge0 10.8.0.0/24 -> 0.0.0.0/32 #catch everything else. ICMP/etc
List of active sessions:
alucard[/]#svcadm restart ipfilter
alucard[/]#/etc/init.d/openvpn start
Starting OpenVPN…
alucard[/]#ifconfig tun0
tun0: flags=10011008d1
inet 10.8.0.1 –> 10.8.0.2 netmask ffffffff
ether 3c:7:0:ff:ff:ff
Tunnel’s up with the right address. Client config:
client
dev tun
proto udp
remote my.dyndns.address 443
resolv-retry infinite #never give up
nobind #don't bind to local address and port
persist-key
persist-tun
ca ca.crt
cert heather.crt
key heather.key
comp-lzo
verb 5
tls-auth ta.key 1
pull #gets everything with a "push" directive in the server's conf file
Connecting a client and testing:
ryan@xerxes ~ $ ping 10.8.0.1
10.8.0.1 is alive
ryan@xerxes ~ $ ping 192.168.0.2
192.168.0.2 is alive
ryan@xerxes ~ $ ping google.com
google.com is alive
ryan@xerxes ~ $ traceroute google.com
traceroute: Warning: google.com has multiple addresses; using 72.14.207.99
traceroute: Warning: Multiple interfaces found; using 192.168.0.8 @ bge0
traceroute to google.com (72.14.207.99), 30 hops max, 40 byte packets
1 10.8.0.1 (10.8.0.1) 8.643 ms 8.704 ms 8.412 ms
2 192.168.0.1 (192.168.0.1) 5.602 ms 1.691 ms 1.458 ms
3 73.237.96.1 (73.237.96.1) 10.583 ms 12.434 ms 18.580 ms
4 ge-1-40-ur01.webster.mn.minn.comcast.net (68.87.179.189) 10.214 ms 11.131 ms *
5 te-8-1-ur02.minnehaha.mn.minn.comcast.net (68.87.174.149) 10.884 ms 11.120 ms *
6 te-8-3-ur01.minnehaha.mn.minn.comcast.net (68.87.174.145) 11.021 ms 12.867 ms *
7 * te-8-1-ar02.roseville.mn.minn.comcast.net (68.87.174.141) 105.276 ms *
8 te-0-0-0-0-cr01.omaha.ne.ibone.comcast.net (68.86.84.29) 27.271 ms 26.469 ms 26.695 ms
9 COMCAST-IP.car2.Denver1.Level3.net (4.79.82.58) 35.925 ms 37.085 ms 43.306 ms
10 te-3-4.car2.Denver1.Level3.net (4.79.82.57) 35.323 ms 40.357 ms 37.765 ms
11 ae-32-56.ebr2.Denver1.Level3.net (4.68.107.190) 50.018 ms 48.416 ms 37.038 ms
12 ae-3.ebr3.Chicago1.Level3.net (4.69.132.62) 44.406 ms 47.588 ms 40.422 ms
13 ae-68.ebr1.Chicago1.Level3.net (4.69.134.57) 42.095 ms 43.703 ms 36.046 ms
14 ae-2.ebr2.NewYork1.Level3.net (4.69.132.66) 74.493 ms 67.525 ms 69.368 ms
15 ae-82-82.csw3.NewYork1.Level3.net (4.69.134.90) 66.745 ms 65.820 ms 69.375 ms
16 ae-33-89.car3.NewYork1.Level3.net (4.68.16.133) 63.640 ms * *
17 GOOGLE-INC.car3.NewYork1.Level3.net (4.71.172.82) 64.239 ms 65.020 ms 65.755 ms
18 72.14.236.215 (72.14.236.215) 68.622 ms 66.218 ms 65.106 ms
19 72.14.233.113 (72.14.233.113) 79.852 ms 78.445 ms 81.719 ms
20 66.249.94.92 (66.249.94.92) 79.104 ms 83.073 ms 81.338 ms
21 72.14.236.134 (72.14.236.134) 89.334 ms 83.721 ms 66.249.94.50 (66.249.94.50) 81.548 ms
22 eh-in-f99.google.com (72.14.207.99) 80.819 ms 79.071 ms 83.579 ms
Everything looks as it should, plus it’s routed through the VPN. Good. Well, good other than Comcast’s bullshit. What the fuck, 4 connections in Minnesota. I’m getting an extra 10 seconds of latency in minnehaha in (presumably) the same datacenter? I can’t fathom why it wouldn’t just immediately go to Roseville, and that 106ms latency in Roseville is ridiculous. Level 3 I’ll forgive because they’re a backbone provider. Comcast, not so much.
I know nobody else will really be interested in reading this, so it’s more for my own benefit should I need to duplicate it than anything, but… Should you need to set up a VPN server, you know who to call.
As an aside, my fileserver’s going to get an exciting 8 port PCI-X SATA card and 8 500GB drives. Another 7.5TB should hold me for a while, plus it’s a lot more spindles for performance. I’m really considering just getting Sun Rays (thin clients) instead of using a full-fledged desktop (they’ll do multi-head, too), and just turning on my Wintendo for games.