OpenVPN tunnel issues & questions



  • Hey folks,
    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.

    removed the configs and routing tables in this post to update the thread.



  • If you are new to OpenVPN i would start with a release version of PFsense, not the 2.0 alpha version not yet tested enough for advanced functions like VPN, bridging, bonding, QinQ, balacing, IPv6 and other advanced QOS toys, very nice to see in the graphic interface, but they will need monthes or certainly one or two years to rise at a final release state.

    Watching other complex projects like Zeroshell or Openwrt, about one - two years is the time needed to get a fully working system. As PFsense 2.0 is one or two step more complex than all other opensource router projects, it will certainly take the same amount of time or more to stabilyze with the impressive actual set of functions, and will certainly need as well FreeBSD specific updates to be really mature for the more complex ones, as opensource OS systems have never been tested with such an impressive set of functions, directly available for everyone in the GUI.

    The problem with advanced functions testing, is that only a very small part of users ( 0.1 - 1% ?) do really have the knowledge, the network, the hardware and or the patience to test them. This explain why a bug can stay for years for advanced functions, without action from the developpers.

    But when you need this one in production, you can't wait for one year more, neither you can't learn all the system to debug yourself the source code. Even if the PFsense team can help you through commercial support, they will not be able to correct a FreeBSD or package bug very fastly. This explain why Cisco do sell hardware today and will for the next couple of years :=) (in fact they have faster hardware too and a full set of functions like ATM, IPv6 and IPv4 Auto QOS fragmentation never seen on Opensource solutions :=(

    If i'm right, inside Pfsense 1.2, OpenVPN is considered as an internal service, so you do not have to worry about firewall rules for it. All is done internally. i'm using it like this for a multi sites routed VPN. You even do not see a TUN interface for IT. This is simpler to use.

    Inside 2.0, you can take the OpenVPN tun interface in the GUI, and apply firewall rules on it, and or NAT, like for other interfaces. This is far more powerfull, but really more complex and error prone.



  • olivier1010, thanks for the very detailed reply.

    I'm

    Admittedly I have a lot to learn but I'll at least admit to knowing what I was getting into with beta software. One of the challenges is my limited time and knowledge but one of benefits is that I can help troubleshoot some of these issues when others cannot afford 2.0 into production.

    That said, I'm going to revise this tread tonight on the progress I have made. Hope it will help the greater good.

    To your final point, I think having more gui options does create some challenges - I have the tunnel up but can only ping b/t the gateways, not on b/t clients. I'm almost sure its a routing problem, but it could be rules…there in lays they challenge. Its not easy to troubleshoot.



  • 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

    Server Config
    /var/etc/openvpn/server1.conf

    # 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 96.253.96.54
    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
    
    

    CLIENT (lynchburgclient)
    /var/etc/openvpn/client1.conf

    # 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 172.15.1.2
    lport 1194
    remote 96.253.96.54 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
    
    

    ROUTES

    Server

    Destination 	Gateway 	Flags 	Refs 	Use 	Mtu 	Netif 	Expire
    default 	96.253.96.1 	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 	 
    96.253.96.0/24 	link#2 	UC 	0 	0 	1500 	dc1 	 
    96.253.96.1 	00:90:1a:a1:1a:18 	UHLW 	2 	29635 	1500 	dc1 	219
    96.253.96.54 	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 	 
    

    Client

    Destination 	Gateway 	Flags 	Refs 	Use 	Mtu 	Netif 	Expire
    default 	172.15.1.1 	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 	 
    172.15.0.0/16 	link#2 	UC 	0 	0 	1500 	dc1 	 
    172.15.1.1 	00:04:dd:2d:49:20 	UHLW 	2 	41498 	1500 	dc1 	291
    172.15.1.2 	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 	 
    


  • 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.


Log in to reply