OpenVPN tunnel issues & questions (is it the routing?)
I originally posted this in the 2.0 beta forum. Since then it has occurred to me that this has more to do with OpenVPN fundamentals than the beta so I thought I'd cross-post it here (hope that is ok).
I am still successful at getting the tunnel to open (I think) but routing is proving to be a challenge still… As always, I'm very appreciative of everyone's time and willingness to offer tips and suggestions.
I've spent the last 24 hours learning a whole lot about OpenVPN, routing and PFsense 2.0. The bad news is that rapid education means I'm still only one step shy of a total novice. However, I think I've found a few bugs - or at least opportunities to learn more.
For the last 18 months or so, I have been using an IPsec tunnel for site-to-site b/t two PFsense boxes. However, I only have one WAN IP these days and I need to forward those IPsec ports to an internal L2TP server. I like OpenVPN and have been using it for road warriors and so it seemed like a good fit for the site-to-site tunnel (particularly if I can one day get layer 2 tunneling through dev tap).
My first question - what is the appropriate way to set up a peer-to-peer (ptp)? Are they both clients? Is one a server and one a client? Are they both servers? None of those combinations seemed to produce a openVPN conf file that looked like what I would expect for a ptp tunnel.
Secondly - there appears to be a bug related to using PSKs. That setting does not appear to be sticky in the client screens - no matter what, the config reverts to SSL/TLS. I understand the security ramifications of using a PSK, but for basic testing its much easier to troubleshoot.
Third - do I need to create interfaces for the OpenVPN virtual adapters? I've noticed they will show up regardless, so I'd prefer not to create them (its just another layer of complexity)...but I have tried both ways.
Finally - I've been able to edit the conf files in /var/etc/openvpn manually and finally got a tunnel started last night. However, I cannot seem to get anything to route at all. I have tried manually assigning the routes with mixed results. Usually I cannot ping either side of the tunnel, on occasion it does not just time out, it errors our in a strange way (see below)
As a note - what I am calling the "remote" machine below is behind another router. Its an any/any setup with a static public IP,but it was the only way the telco could set up the wonky T-1 ... the result is that the remote PFsense box has a bogon address for its WAN.
NOTE: I have deleted the configs that were here b/c they were so broken. I did not want to confuse anyone doing a search in the future. See below for the progress of this setup
I didn't catch you on IRC again, so I'll reply here.
#1: Be sure you have added firewall rules for OpenVPN on your 2.0 system (Firewall > Rules, OpenVPN tab)
#2: See the new FAQ entry I just added:
In my test setup, I was able to reach a subnet behind my 2.0 test system, even though I was not able to ping the OpenVPN adapter addresses.
Thanks everyone, particularly Jim-P in IRC…
made lots of progress
from my 2.0 beta thread
As indicated above, I've had some progress ... its still not working full, but I hope there can be some back scratching here
Glad to be a part of testing 2.0 but could also use some basic OpenVPN help
The config below creates a successful tunnel between two PFsense 2.0 beta boxes. From each PFsense box, I can ping resources on the other network. However, network resources cannot ping across the VPN. <--thats where I could use some help ;D
I have also added comments in the code below where the GUI produced something different or did not produce anything at all
# cat server1.conf dev ovpns1 dev-type tun dev-node /dev/tun1 writepid /var/run/openvpn_server1.pid #user nobody #group nobody daemon keepalive 10 60 ping-timer-rem persist-tun persist-key proto udp mode server #not inserted by the GUI, but needed cipher AES-256-CBC client-config-dir /var/etc/openvpn-csc #not inserted by GUI, but critical - specifies where to look for client configs up /etc/rc.filter_configure down /etc/rc.filter_configure local 184.108.40.206 tls-server #ifconfig 192.168.123.1 192.168.123.2 #inserted by gui, but I think this wrong for ptp setups server 192.168.123.0 255.255.255.0 #not inserted by gui but key to making my setup work lport 1194 management 127.0.0.1 1194 max-clients 250 push "route 10.1.1.0 255.255.255.0" push "route 10.1.5.0 255.255.255.0" #entered into the gui, but was not in conf files, had to manually add route 10.1.5.0 255.255.255.0 #missing in GUI, required for ptp setup ca /var/etc/openvpn/server1.ca cert /var/etc/openvpn/server1.cert key /var/etc/openvpn/server1.key dh /etc/dh-parameters.1024 comp-lzo client-to-client #checked the box in GUI, did not add to conf, had to manually add it verb 3 #this is the default for PFsense, I added the line so I could increase to 6 or 9 for testing
Client specific code in /var/etc/openvpn-csc/
# cat ../openvpn-csc/lynchburgclient iroute 10.1.5.0 255.255.255.0 #required for ptp, no place in GUI to add this ifconfig-push 192.168.123.5 192.168.123.6 #required for ptp, no place in GUI to add this client-to-client #required for ptp, no place in GUI to add this
# cat /var/etc/openvpn/client1.conf dev ovpnc1 dev-type tun dev-node /dev/tun1 writepid /var/run/openvpn_client1.pid #user nobody #group nobody daemon client #this was the *most* critical one word, not populated by gui, again this was KEY keepalive 10 60 ping-timer-rem persist-tun persist-key proto udp cipher AES-256-CBC up /etc/rc.filter_configure down /etc/rc.filter_configure local 220.127.116.11 lport 1194 remote 18.104.22.168 1194 comp-lzo tls-client #ifconfig 192.168.123.5 192.168.123.6 #put in by GUI, but is a mistake to include here, should be pushed from CCD ca /var/etc/openvpn/ca.crt #not populated by gui despite selecting ssl/tls w/ proper certs, this is HUGE cert /var/etc/openvpn/lynchburg.crt #not populated by gui despite selecting ssl/tls w/ proper certs, this is HUGE key /var/etc/openvpn/lynchburg.key #not populated by gui despite selecting ssl/tls w/ proper certs, this is HUGE verb 3 #for my testing
Destination Gateway Flags Refs Use Mtu Netif Expire default 22.214.171.124 UGS 0 8307352 1500 dc1 10.1.1.0/24 link#5 UC 0 0 1500 xl0 10.1.1.1 00:06:5b:c5:42:01 UHLW 1 10 16384 lo0 10.1.1.15 00:0d:93:4e:68:5c UHLW 1 30745 1500 xl0 864 10.1.1.27 00:16:cb:a8:1d:7f UHLW 1 38950 1500 xl0 1186 10.1.1.40 00:06:5b:99:34:ce UHLW 1 16279 1500 xl0 1164 10.1.1.65 00:1e:8c:91:8a:27 UHLW 1 1849710 1500 xl0 624 10.1.1.100 00:1f:f3:5a:5f:af UHLW 1 790 1500 xl0 1043 10.1.1.101 00:1f:5b:c6:26:e5 UHLW 1 37158 1500 xl0 782 10.1.1.136 00:02:b9:af:c9:80 UHLW 1 3 1500 xl0 1071 10.1.1.150 00:16:cb:a5:e0:ea UHLW 1 1 1500 xl0 243 10.1.1.154 00:16:cb:a5:fe:24 UHLW 1 217 1500 xl0 640 10.1.1.160 00:1d:4f:0b:d2:e4 UHLW 1 2241 1500 xl0 1039 10.1.1.188 00:0e:08:da:31:af UHLW 1 0 1500 xl0 665 10.1.2.0/24 link#3 UC 0 0 1500 dc2 10.1.2.43 00:13:d3:84:5d:e0 UHLW 1 189 1500 dc2 279 10.1.5.0/24 192.168.123.2 UGS 0 5505 1500 ovpns1 10.1.20.0/24 link#1 UC 0 0 1500 dc0 126.96.36.199/24 link#2 UC 0 0 1500 dc1 188.8.131.52 00:90:1a:a1:1a:18 UHLW 2 29635 1500 dc1 219 184.108.40.206 00:18:01:30:c9:61 UHLW 1 7016 16384 lo0 127.0.0.1 127.0.0.1 UH 0 406 16384 lo0 192.168.123.0/24 192.168.123.2 UGS 0 85 1500 ovpns1 192.168.123.2 192.168.123.1 UH 2 0 1500 ovpns1
Destination Gateway Flags Refs Use Mtu Netif Expire default 220.127.116.11 UGS 0 28445 1500 dc1 10.1.1.0/24 192.168.123.6 UGS 0 1614 1500 ovpnc1 10.1.5.0/24 link#3 UC 0 0 1500 xl0 10.1.5.1 00:06:5b:68:89:9b UHLW 1 6 16384 lo0 10.1.5.5 00:14:51:6f:8b:16 UHLW 1 1 1500 xl0 1065 10.1.5.100 00:17:f2:da:e0:b4 UHLW 1 865 1500 xl0 457 10.1.5.228 00:50:94:fb:e2:78 UHLW 1 1 1500 xl0 18 10.1.5.232 00:1f:f3:3f:0a:5e UHLW 1 1487 1500 xl0 839 10.1.6.0/24 link#1 UC 0 0 1500 dc0 127.0.0.1 127.0.0.1 UH 0 1 16384 lo0 18.104.22.168/16 link#2 UC 0 0 1500 dc1 22.214.171.124 00:04:dd:2d:49:20 UHLW 2 41498 1500 dc1 291 126.96.36.199 00:14:bf:54:8a:7a UHLW 1 79 16384 lo0 192.168.123.0/24 192.168.123.6 UGS 0 38 1500 ovpnc1 192.168.123.6 192.168.123.5 UH 2 0 1500 ovpnc1
Edited to add -
When I ping from clients on either side of the VPN, the firewall logs seem to suggest things are working
IE: from Machine X (10.1.5.100) on Network B (10.1.5.0/24)
ssh 10.1.1.100 (Machine A on Network A)
Firewall Log shows:
PASS Apr 9 22:13:28 LAN 10.1.5.100:53347 10.1.1.101:22 TCP:S
From Machine A (10.1.1.100) on Network A (10.1.1.0/24)
ssh 10.1.5.100 (Machine X on Network B)
PASS Apr 9 22:13:09 ovpns1 10.1.5.100:53343 10.1.1.101:22 TCP:S
Wanted to close the loop on this one …
Did a fresh install on both ends and used my hand-coded confs (above) and it worked!
presumably there was something sticking around from the 1.2.x upgrade to 2.0 ...
These confs work but the ones produced from the GUI do not.