OpenVPN-server on FreeNAS - Clients can connect but nothing more

Status
Not open for further replies.

LarsCarlsson

Cadet
Joined
Feb 21, 2016
Messages
4
Hi,

I am trying set up a OpenVPN-Server on my FreeNAS within a jail to allow off-site clients access the storage over the internet. I like to set it up so that only traffic from the client that are towards the FreeNAS are routed to the VPN-connection, nothing more and not the general internet traffic.

I have been following this guide to the best of my ability.

10.0.0.0 /24 is my regular home network
10.0.0.1 /24 is my router
10.0.0.100 /24 is my FreeNAS
10.0.0.103 /24 is my OpenVPN-jail
10.0.1.0 /24 is the network where the VPN-clients will end up

Port 1194 is forwarded on my router towards 10.0.0.103.

Clients can connect to the VPN-server from any off-site location without any problem. From this I draw the conclusion that my keys, certificates and port forwarding are working correct. But nothing else work. Clients can’t access any of the services running on my FreeNAS. They can neither ping any nodes on the 10.0.0.0 /24 network nor can they ping 10.0.1.1 witch’s supposed to be the VPN-server address within the 10.0.1.0 /24-network.

I suspect that I have got something wrong in my configuration, but to figure out what exceeds my ability. I someone had the time to look in to it I would be grateful. Maybe it is something really simple.

My server configuration file looks like this:


openvpn.config
Code:
port 1194
proto udp
dev tun
ca /mnt/openvpn/keys/ca.crt
cert /mnt/openvpn/keys/server.crt
key /mnt/openvpn/keys/server.key
dh /mnt/openvpn/keys/dh1024.pem
server 10.0.1.0 255.255.255.0
ifconfig-pool-persist ipp.txt
push "route 10.0.0.0 255.255.255.0"
route 10.0.0.103 255.255.255.0 10.0.1.1
keepalive 10 120
group nobody
user nobody
comp-lzo
persist-key
persist-tun
status openvpn-status.log
log openvpn.log
verb 3



And the clients configuration file:

client.ovpn
Code:
remote [my-dyndns-addres] 1194

client
remote-cert-tls server
dev tun
proto udp
resolv-retry infinite
nobind
persist-key
persist-tun
float

ca ca.crt
cert [client-name].crt
key [client-name].key



The file “/etc/rc.conf” looks like this:
Code:
portmap_enable="NO"
sshd_enable="YES"
sendmail_enable="NO"
sendmail_submit_enable="NO"
sendmail_outbound_enable="NO"
sendmail_msp_queue_enable="NO"
hostname="OpenVPN"
devfs_enable="YES"
devfs_system_ruleset="devfsrules_common"
inet6_enable="YES"
ip6addrctl_enable="YES"
openvpn_enable="YES"
openvpn_if="tun"
openvpn_configfile="/mnt/openvpn/openvpn.conf"
openvpn_dir="/mnt/openvpn"
cloned_interfaces="tun"
gateway_enable="YES"
firewall_enable="YES"
firewall_script="/usr/local/etc/ipfw.rules"



The file “/usr/local/etc/ipfw.rules” is set up like the following:
Code:
#!/bin/sh

EPAIR=$(/sbin/ifconfig -l | tr " " "\n" | /usr/bin/grep epair)
ipfw -q -f flush
ipfw -q nat 1 config if ${EPAIR}
ipfw -q add nat 1 all from 10.0.1.0/24 to any out via ${EPAIR}
ipfw -q add nat 1 all from any to any in via ${EPAIR}
TUN=$(/sbin/ifconfig -l | tr " " "\n" | /usr/bin/grep tun)
ifconfig ${TUN} name tun0



When a client connects the following output writes in to openvpn.log:
Code:
Sat Apr  2 17:28:43 2016 [client-internet-ip]:[client-port] TLS: Initial packet from [AF_INET][client-internet-ip]:[client-port], sid=6226da1c 57c47941
Sat Apr  2 17:28:43 2016 [client-internet-ip]:[client-port] VERIFY OK: depth=1, C=[contry], ST=[state], L=[city], O=[organisation], CN=[client-name], emailAddress=
Sat Apr  2 17:28:43 2016 [client-internet-ip]:[client-port] VERIFY OK: depth=0, C=[contry], ST=[state], O=[organisation], CN=[client-namn], emailAddress=[email]
Sat Apr  2 17:28:43 2016 [client-internet-ip]:[client-port] WARNING: 'link-mtu' is used inconsistently, local='link-mtu 1542', remote='link-mtu 1541'
Sat Apr  2 17:28:43 2016 [client-internet-ip]:[client-port] WARNING: 'comp-lzo' is present in local config but missing in remote config, local='comp-lzo'
Sat Apr  2 17:28:43 2016 [client-internet-ip]:[client-port] Data Channel Encrypt: Cipher 'BF-CBC' initialized with 128 bit key
Sat Apr  2 17:28:43 2016 [client-internet-ip]:[client-port] Data Channel Encrypt: Using 160 bit message hash 'SHA1' for HMAC authentication
Sat Apr  2 17:28:43 2016 [client-internet-ip]:[client-port] Data Channel Decrypt: Cipher 'BF-CBC' initialized with 128 bit key
Sat Apr  2 17:28:43 2016 [client-internet-ip]:[client-port] Data Channel Decrypt: Using 160 bit message hash 'SHA1' for HMAC authentication
Sat Apr  2 17:28:43 2016 [client-internet-ip]:[client-port] Control Channel: TLSv1, cipher TLSv1/SSLv3 DHE-RSA-AES256-SHA, 1024 bit RSA
Sat Apr  2 17:28:43 2016 [client-internet-ip]:[client-port] [[client-namn]] Peer Connection Initiated with [AF_INET][client-internet-ip]:[client-port]
Sat Apr  2 17:28:43 2016 [client-namn]/[client-internet-ip]:[client-port] MULTI_sva: pool returned IPv4=10.0.1.6, IPv6=(Not enabled)
Sat Apr  2 17:28:43 2016 [client-namn]/[client-internet-ip]:[client-port] MULTI: Learn: 10.0.1.6 -> [client-namn]/[client-internet-ip]:[client-port]
Sat Apr  2 17:28:43 2016 [client-namn]/[client-internet-ip]:[client-port] MULTI: primary virtual IP for [client-namn]/[client-internet-ip]:[client-port]: 10.0.1.6
Sat Apr  2 17:28:46 2016 [client-namn]/[client-internet-ip]:[client-port] PUSH: Received control message: 'PUSH_REQUEST'
Sat Apr  2 17:28:46 2016 [client-namn]/[client-internet-ip]:[client-port] send_push_reply(): safe_cap=940
Sat Apr  2 17:28:46 2016 [client-namn]/[client-internet-ip]:[client-port] SENT CONTROL [[client-namn]]: 'PUSH_REPLY,route 10.0.0.0 255.255.255.0,route 10.0.1.1,topology net30,ping 10,ping-restart 120,ifconfig 10.0.1.6 10.0.1.5' (status=1)
Sat Apr  2 17:28:56 2016 [client-namn]/[client-internet-ip]:[client-port] Bad LZO decompression header byte: 42
Sat Apr  2 17:29:07 2016 [client-namn]/[client-internet-ip]:[client-port] Bad LZO decompression header byte: 42
Sat Apr  2 17:29:21 2016 [client-namn]/[client-internet-ip]:[client-port] Bad LZO decompression header byte: 42
Sat Apr  2 17:29:21 2016 [client-namn]/[client-internet-ip]:[client-port] Bad LZO decompression header byte: 69
Sat Apr  2 17:29:23 2016 [client-namn]/[client-internet-ip]:[client-port] Bad LZO decompression header byte: 69
Sat Apr  2 17:29:24 2016 [client-namn]/[client-internet-ip]:[client-port] Bad LZO decompression header byte: 69
Sat Apr  2 17:29:24 2016 [client-namn]/[client-internet-ip]:[client-port] Bad LZO decompression header byte: 69
Sat Apr  2 17:29:27 2016 [client-namn]/[client-internet-ip]:[client-port] Bad LZO decompression header byte: 69
Sat Apr  2 17:29:28 2016 [client-namn]/[client-internet-ip]:[client-port] Bad LZO decompression header byte: 69
Sat Apr  2 17:29:34 2016 [client-namn]/[client-internet-ip]:[client-port] Bad LZO decompression header byte: 69
Sat Apr  2 17:29:34 2016 [client-namn]/[client-internet-ip]:[client-port] Bad LZO decompression header byte: 69
Sat Apr  2 17:29:44 2016 [client-namn]/[client-internet-ip]:[client-port] Bad LZO decompression header byte: 42
Sat Apr  2 17:29:45 2016 [client-namn]/[client-internet-ip]:[client-port] Bad LZO decompression header byte: 69
Sat Apr  2 17:29:48 2016 [client-namn]/[client-internet-ip]:[client-port] Bad LZO decompression header byte: 69
Sat Apr  2 17:29:52 2016 [client-namn]/[client-internet-ip]:[client-port] Bad LZO decompression header byte: 69
Sat Apr  2 17:29:52 2016 [client-namn]/[client-internet-ip]:[client-port] Bad LZO decompression header byte: 69
Sat Apr  2 17:29:54 2016 [client-namn]/[client-internet-ip]:[client-port] Bad LZO decompression header byte: 69
Sat Apr  2 17:29:55 2016 [client-namn]/[client-internet-ip]:[client-port] Bad LZO decompression header byte: 69
Sat Apr  2 17:29:55 2016 [client-namn]/[client-internet-ip]:[client-port] Bad LZO decompression header byte: 69
Sat Apr  2 17:30:01 2016 [client-namn]/[client-internet-ip]:[client-port] Bad LZO decompression header byte: 69
Sat Apr  2 17:30:02 2016 [client-namn]/[client-internet-ip]:[client-port] Bad LZO decompression header byte: 69
Sat Apr  2 17:30:12 2016 [client-namn]/[client-internet-ip]:[client-port] Bad LZO decompression header byte: 42[/CODE]

//LarsCarlsson
 
Last edited:

LarsCarlsson

Cadet
Joined
Feb 21, 2016
Messages
4
Hi again :)

I have added the following line in the client config:
Code:
comp-lzo


Now the client can connect to 10.0.0.103 and 10.0.1.1, but nothing else. This also means that the lines 18-39 in the log output doesn't show up anymore.

Maybe this was a part of the problem, but the must be something more as well.
 

zoomzoom

Guru
Joined
Sep 6, 2015
Messages
677
A few things I noticed:

Server Config
  • For troubleshooting, change proto udp to proto tcp in server and client config
    • Please post output of openvpn.log after changing and setting verb 7
  • Missing server IP
    • ifconfig "10.0.1.1 255.255.255.0"
  • Missing ta.key, which prevents MITM attacks
    • openvpn -genkey -secret which will output a file named ta.key
Client Config
  • Missing cipher
    • cipher AES-256-CBC
  • Missing verbosity
    • verb 7
  • Missing option to not cache authentication
    • auth-nocache
  • remote-cert-tls is depreciated and should not be utilized (created only for Netscape browser)
    • Instead, one needs to use openssl and a openssl.cnf to generate:
      • Server Cert with EKU (Extended Key Usage) Server Auth
      • Client Certs with EKU Client Auth
    • remote-cert-tls will then be replaced with remote-cert-ku f8
I'm attaching the server and client configs I would recommend to use, however the server cert will need to be tweaked slightly for BSD. I am also attaching an OpenSSL.cnf you can utilize to create a CA specifically for OpenVPN (I've also included the commands required, as well as some other pertinent information towards the bottom, starting around line 315).
  • It's recommended to create client keys that are password protected. Currently, the openssl.cnf has encrypt_key = yes commented out, and if you want each client key to require a password to authenticate, uncomment that line.
The openssl.cnf is formatted with tab spacing from Visual Studio 2015 (I believe a spacing of 4), and if you've never utilized an openssl.cnf before, I strongly recommend aligning everything if the alignment of options is off in whatever program you open it in, as it will make it far easier to read, making it much easier on you to see what everything is and what needs to be edited for your environment.
  • If you need help understanding what you need to edit in the openssl.cnf, please let me know and I can walk you through it.
  • It's also not recommended to create your CA and certs on a server... they should be created on a PC/workstation. The CA, specifically it's key, should be encrypted after you are done generating and signing certs. I recommend GnuPG, generating a personal cert with (minimum 2048), configuring it with a complex password, and then using the personal cert to encrypt your CA key

I've included two openvpn server configs in the zip, one for OpenWRT (the original) and one for BSD. which may need to be tweaked slightly, as I only removed the OpenWRT specific coding
 

Attachments

  • OpenVPN Config.zip
    6.6 KB · Views: 296
Last edited:

water.wang0

Cadet
Joined
Aug 10, 2016
Messages
2
A few things I noticed:

Server Config
  • For troubleshooting, change proto udp to proto tcp in server and client config
    • Please post output of openvpn.log after changing and setting verb 7
  • Missing server IP
    • ifconfig "10.0.1.1 255.255.255.0"
  • Missing ta.key, which prevents MITM attacks
    • openvpn -genkey -secret which will output a file named ta.key
Client Config
  • Missing cipher
    • cipher AES-256-CBC
  • Missing verbosity
    • verb 7
  • Missing option to not cache authentication
    • auth-nocache
  • remote-cert-tls is depreciated and should not be utilized (created only for Netscape browser)
    • Instead, one needs to use openssl and a openssl.cnf to generate:
      • Server Cert with EKU (Extended Key Usage) Server Auth
      • Client Certs with EKU Client Auth
    • remote-cert-tls will then be replaced with remote-cert-ku f8
I'm attaching the server and client configs I would recommend to use, however the server cert will need to be tweaked slightly for BSD. I am also attaching an OpenSSL.cnf you can utilize to create a CA specifically for OpenVPN (I've also included the commands required, as well as some other pertinent information towards the bottom, starting around line 315).
  • It's recommended to create client keys that are password protected. Currently, the openssl.cnf has encrypt_key = yes commented out, and if you want each client key to require a password to authenticate, uncomment that line.
The openssl.cnf is formatted with tab spacing from Visual Studio 2015 (I believe a spacing of 4), and if you've never utilized an openssl.cnf before, I strongly recommend aligning everything if the alignment of options is off in whatever program you open it in, as it will make it far easier to read, making it much easier on you to see what everything is and what needs to be edited for your environment.
  • If you need help understanding what you need to edit in the openssl.cnf, please let me know and I can walk you through it.
  • It's also not recommended to create your CA and certs on a server... they should be created on a PC/workstation. The CA, specifically it's key, should be encrypted after you are done generating and signing certs. I recommend GnuPG, generating a personal cert with (minimum 2048), configuring it with a complex password, and then using the personal cert to encrypt your CA key

I've included two openvpn server configs in the zip, one for OpenWRT (the original) and one for BSD. which may need to be tweaked slightly, as I only removed the OpenWRT specific coding
I tried your configuration file, but the lan server still can not be accessed from vpn client although the openvpn gui show "client is now connected".
Could you help check what's wrong with my openvpn?

root@OpenVPN2:/ # ipfw list
00100 nat 1 ip from 192.168.3.0/24 to any out via {epair0b}
00200 nat 1 ip from any to any in via epair0b
65535 allow ip from any to any

root@OpenVPN2:/ # sockstat -4 -l
USER COMMAND PID FD PROTO LOCAL ADDRESS FOREIGN ADDRESS
nobody openvpn 80798 6 tcp4 192.168.2.21:10012 *:*
root syslogd 80764 7 udp4 *:514 *:*


Server config file:
local 192.168.2.21
port 10012
proto tcp
dev tun
#dev tun0
#topology subnet

ca /mnt/openvpn/keys/pki/ca.crt
cert /mnt/openvpn/keys/pki/issued/server.crt
key /mnt/openvpn/keys/pki/private/server.key
dh /mnt/openvpn/keys/pki/dh.pem

server 192.168.3.0 255.255.255.0
#server 192.168.3.1 255.255.255.0
#ifconfig 192.168.3.1 255.255.255.0

ifconfig-pool-persist ipp.txt
push "route 192.168.2.0 255.255.255.0"
#push "route 192.168.2.21 255.255.255.0 192.168.3.1"
#push "route-gateway 192.168.3.1"
push "redirect-gateway def1"
#push "redirect-gateway 192.168.3.1"
#route 192.168.2.0 255.255.255.0
route 192.168.2.21 255.255.255.0 192.168.3.1

keepalive 10 120
group nobody
user nobody
comp-lzo
persist-key
persist-tun
verb 3
 

zoomzoom

Guru
Joined
Sep 6, 2015
Messages
677
@water.wang0 It appears you're missing a few things from the server config (possibly the client config as well)

Missing Config Options

I've never been able to get a SSL VPN to work with the local bind command set, and there's simply not enough information from OpenVPN on when this option should and should not be utilized.
  • I recommend removing it until you're able to get the VPN up and running with all routes successfully accessed prior to adding it back
    • Remove: local 192.168.2.21
It's recommended to use the subnet topology:
  • Add: topology subnet
    • net30 is obsolete and depreciated
DNS push for whatever LAN you're trying to access:
  • I believe the LAN subnet you're trying to access is 192.168.2.0/24? If so:
    • Add: push "dhcp-option DNS 192.168.2.1"
      • This assumes you're using .1 for your LAN DHCP server, however it may be .21 since you didn't specify what subnets/IPs were which. Once modified, restart the OpenVPN server
Redirect gateway DNS [VPN Server's IP] must also be pushed:
  • Add: push "dhcp-option DNS 192.168.3.1"
A few firewall rules are missing:
  • Check out the required firewall rules on an old wiki I wrote for OpenWrt.
    • It's easier to send you there than to lengthen this post considerably.
  • As well as the required Redirect Gateway Firewall Rules
I highly recommend:
I believe the redirect must have local at the end of the command:
  • I've never configured a SSL VPN for redirect gateway, so I recommend making the changes above first, seeing if the VPN routes traffic correctly or not, and only if it does not, try adding local to the end of the command
    • Add: push "redirect-gateway def1 local"
If these do not solve the issue, please do the following:
  1. Change server config verbosity to 7: verb 7
    • Log options are missing from server config:
      • log "/tmp/openvpn.log"
      • status "/tmp/openvpn-status.log"
  2. Change client config verbosity to 5: verb 5
  3. Kill client connection(s), restart VPN server, then reconnect client(s)
  4. Please post output of:
    • Please post all logs & configs within CODE brackets
    1. Server Logs:
      • /tmp/openvpn.log
      • /tmp/openvpn-status.log
    2. Client Config
    3. Firewall log
      • Sanitize of all sensitive info prior to posting (i.e. MACs, WAN IP, etc.)
      • Please only include output after the restart of the VPN server & after attempting to access the LAN routes via the client(s)

Additional Recommendations
  • Depending on what you're using the VPN for, you may want to encrypt the traffic.
    • For example, if you're using it to access a LAN remotely, you want the traffic encrypted
  • Checkout the custom OpenVPN server and client configs I have on GitHub
    • You'll also benefit from reading the ReadMe in the OpenVPN folder
  • If you created your certs using easy-RSA, I highly recommend ditching those and using an openssl.cnf to create a CA and certs, as easy-RSA does not create secure enough CAs or certs.
    • I have a custom openssl.cnf on my GitHub as well, with all commands required starting at line 507
      • You'll also benefit from reading the ReadMe in the OpenSSL folder
  • My guess is you changed the protocol to TCP for troubleshooting, however if you originally had it configured for TCP, once done troubleshooting, it needs to be changed to UDP: proto udp
    • TCP cannot efficiently encapsulate itself; however, TCP should always be utilized when troubleshooting
  • You'll want to tune your buffer and MTU settings
 
Last edited:
Status
Not open for further replies.
Top