OPNsense Forum

English Forums => Development and Code Review => Topic started by: emfabox on February 04, 2018, 08:35:43 pm

Title: Testing open connect server ocserv
Post by: emfabox on February 04, 2018, 08:35:43 pm
Hi,

the openconnect  client plugin inspired me to play with ocserv - got all necessary packages build and the service up and running but some troubles with the tunnel device name it looks like opnsense does not recognize those interfaces ... sbin/ifconfig tun0 name ocvpnc1 does the trick temporarily so I am asking the real greeks ...

Thank you!
Title: Re: Testing open connect server ocserv
Post by: mimugmail on February 04, 2018, 10:13:27 pm
Yep, to have to rename it, tunX wont be recognized by OPN

https://github.com/opnsense/plugins/blob/master/security/openconnect/src/etc/rc.d/opnsense-openconnect#L53
Title: Re: Testing open connect server ocserv
Post by: emfabox on February 05, 2018, 08:22:29 am
Thank you.

the issue is this does only the trick after the fist connection is established ...  :(

so the name part only works after the fist connection ...

---
root@zero:/usr/local/etc/rc.d # ./opnsense-ocserv start
starting ocserv
note: setting 'file' as supplemental config option
ifconfig: interface tun6 does not exist
ifconfig: interface ocvpn0 does not exist
--



tun6: flags=8051<UP,POINTOPOINT,RUNNING,MULTICAST> metric 0 mtu 1406
   options=80000<LINKSTATE>
   inet 192.168.10.1 --> 192.168.10.222  netmask 0xffffffff
   inet6 fe80::201:2eff:fe70:6b4e%tun6 prefixlen 64 scopeid 0x11
   nd6 options=23<PERFORMNUD,ACCEPT_RTADV,AUTO_LINKLOCAL>
   groups: tun
   Opened by PID 6680

-->
root@zero:/usr/local/etc/rc.d # ifconfig tun6 name ocvpns0
ocvpns0
root@zero:/usr/local/etc/rc.d # ifconfig ocvpns0 group ocvpn
root@zero:/usr/local/etc/rc.d #

ocvpns0: flags=8051<UP,POINTOPOINT,RUNNING,MULTICAST> metric 0 mtu 1406
   options=80000<LINKSTATE>
   inet 192.168.10.1 --> 192.168.10.222  netmask 0xffffffff
   inet6 fe80::201:2eff:fe70:6b4e%ocvpns0 prefixlen 64 scopeid 0x11
   nd6 options=23<PERFORMNUD,ACCEPT_RTADV,AUTO_LINKLOCAL>
   groups: tun ocvpn
   Opened by PID 6680

---
ocvpns0: flags=8010<POINTOPOINT,MULTICAST> metric 0 mtu 1406
   options=80000<LINKSTATE>
   nd6 options=23<PERFORMNUD,ACCEPT_RTADV,AUTO_LINKLOCAL>
   groups: tun ocvpn
---

stopping the client connection destroys the interface ...

ocvpns0: flags=8010<POINTOPOINT,MULTICAST> metric 0 mtu 1406
   options=80000<LINKSTATE>
   nd6 options=23<PERFORMNUD,ACCEPT_RTADV,AUTO_LINKLOCAL>
   groups: tun ocvpn
tun7: flags=8051<UP,POINTOPOINT,RUNNING,MULTICAST> metric 0 mtu 1406
   options=80000<LINKSTATE>
   inet 192.168.10.1 --> 192.168.10.222  netmask 0xffffffff
   inet6 fe80::201:2eff:fe70:6b4e%tun7 prefixlen 64 scopeid 0x12
   nd6 options=23<PERFORMNUD,ACCEPT_RTADV,AUTO_LINKLOCAL>
   groups: tun
   Opened by PID 6680
---

but without changing the interface name it stays ...

ocvpns0: flags=8010<POINTOPOINT,MULTICAST> metric 0 mtu 1406
   options=80000<LINKSTATE>
   nd6 options=23<PERFORMNUD,ACCEPT_RTADV,AUTO_LINKLOCAL>
   groups: tun ocvpn
tun7: flags=8051<UP,POINTOPOINT,RUNNING,MULTICAST> metric 0 mtu 1406
   options=80000<LINKSTATE>
   inet 192.168.10.1 --> 192.168.10.222  netmask 0xffffffff
   inet6 fe80::201:2eff:fe70:6b4e%tun7 prefixlen 64 scopeid 0x12
   nd6 options=23<PERFORMNUD,ACCEPT_RTADV,AUTO_LINKLOCAL>
   groups: tun
   Opened by PID 6680

....

any idea ...

thank you


Title: Re: Testing open connect server ocserv
Post by: mimugmail on February 05, 2018, 09:57:42 am
No, havent played with ocserv yet since compilation crashed last time I test it.
Title: Re: Testing open connect server ocserv
Post by: emfabox on February 05, 2018, 10:27:33 am
could provide packages build on OPNsense 18.1 devel this weekend ...

ocserv-0.11.10.txz
gnutls-3.5.17.txz
protobuf-c-1.3.0_1.txz
talloc-2.1.10_1.txz
radcli-1.2.8.txz
oath-toolkit-2.6.2.txz

....

the device name would not hurt if there is a way to allow incomming traffic on it ...

---
openwrt does the trick https://github.com/openwrt/packages/tree/master/net/ocserv
 (https://github.com/openwrt/packages/tree/master/net/ocserv)

Firewall Log:
--------
Action
block
DataLength
0
DestIP
192.168.30.125
DestPort
80
Direction
in
FilterData
21,,,0,tun6,match,block,in,4,0x0,,64,0,0,DF,6,tcp,64,192.168.10.222,192.168.30.125,50338,80,0,S,3025539627,,65535,,mss;nop;wscale;nop;nop;TS;sackOK;eol
Flags
DF
ID
0
IPVersion
4
Interface
tun6
Length
64
Offset
0
Options
mss;nop;wscale;nop;nop;TS;sackOK;eol
Protocol
tcp
ProtocolID
6
Reason
match
RuleNumber
21
Sequence
3025539627
SourceIP
192.168.10.222
SourcePort
50338
TCPFlags
S
TOS
0x0
TTL
64
Tracker
0
Window
65535
facility
local0
full_message
<134>Feb  5 10:04:18 filterlog: 21,,,0,tun6,match,block,in,4,0x0,,64,0,0,DF,6,tcp,64,192.168.10.222,192.168.30.125,50338,80,0,S,3025539627,,65535,,mss;nop;wscale;nop;nop;TS;sackOK;eol
level
6
message
filterlog: 21,,,0,tun6,match,block,in,4,0x0,,64,0,0,DF,6,tcp,64,192.168.10.222,192.168.30.125,50338,80,0,S,3025539627,,65535,,mss;nop;wscale;nop;nop;TS;sackOK;eol
source
zero.xxxx.com
timestamp
2018-02-05T09:04:18.000Z
-----------------




Title: Re: Testing open connect server ocserv
Post by: mimugmail on February 06, 2018, 03:55:22 pm
Ok, I was able to compile it on another machine. Havent tested it yet but in config there is:

# The name of the tun device
device = vpns


Isnt this ok?
Title: Re: Testing open connect server ocserv
Post by: emfabox on February 07, 2018, 09:00:06 am
Hi,

that's in my conf too ... but it looks like freebsd does ignore it  :(


on linux (debian) the device changes to vpns+

vpns0     Link encap:UNSPEC  HWaddr 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00 
          inet addr:192.168.1.1  P-t-P:192.168.1.222  Mask:255.255.255.255
          UP POINTOPOINT RUNNING  MTU:1406  Metric:1
          RX packets:192 errors:0 dropped:0 overruns:0 frame:0
          TX packets:91 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:500
          RX bytes:66337 (66.3 KB)  TX bytes:42741 (42.7 KB)

on freebsd (opnsense) it stays with tun+

tun0: flags=8051<UP,POINTOPOINT,RUNNING,MULTICAST> metric 0 mtu 1406
   options=80000<LINKSTATE>
   inet 192.168.1.1 --> 192.168.1.222  netmask 0xffffffff
   inet6 fe80::20c:29ff:fece:c63b%tun0 prefixlen 64 scopeid 0x3
   nd6 options=21<PERFORMNUD,AUTO_LINKLOCAL>
   groups: tun
   Opened by PID 7786

thank you


Title: Re: Testing open connect server ocserv
Post by: bobbythomas on February 16, 2018, 07:15:28 pm
Ok, I was able to compile it on another machine. Havent tested it yet but in config there is:

# The name of the tun device
device = vpns


Isnt this ok?

A port for FreeBSD is available for OpenConnect server, did you try that?
https://www.freshports.org/net/ocserv/
http://ocserv.gitlab.io/www/packages.html

Thank you,
Regards,
Bobby Thomas
Title: Re: Testing open connect server ocserv
Post by: mimugmail on February 28, 2018, 10:04:33 pm
Ok, I was able to connect and renamed the interface. But second attempt created again a tun+1, perhaps we need some scripting magic from Ad to make this compatible to OPNsense :)
Title: Re: Testing open connect server ocserv
Post by: andrewp on March 14, 2018, 06:10:11 am
I have tried to install OpenConnect Server on my OPNsense running in Virtual Box and it seems to work.
This is what I had to do to make it cooperate with OPNsense:

 - Install OpenConnect Server and all dependencies from FreeBSD repository
 
Code: [Select]
    pkg add -f https://pkg.freebsd.org/FreeBSD:11:amd64/latest/All/libunistring-0.9.9.txz
    pkg add -f https://pkg.freebsd.org/FreeBSD:11:amd64/latest/All/libidn2-2.0.4.txz
    pkg add -f https://pkg.freebsd.org/FreeBSD:11:amd64/latest/All/libtasn1-4.13.txz
    pkg add -f https://pkg.freebsd.org/FreeBSD:11:amd64/latest/All/p11-kit-0.23.10.txz
    pkg add -f https://pkg.freebsd.org/FreeBSD:11:amd64/latest/All/tpm-emulator-0.7.4_2.txz
    pkg add -f https://pkg.freebsd.org/FreeBSD:11:amd64/latest/All/trousers-0.3.14_2.txz
    pkg add -f https://pkg.freebsd.org/FreeBSD:11:amd64/latest/All/gnutls-3.5.18.txz
    pkg add -f https://pkg.freebsd.org/FreeBSD:11:amd64/latest/All/libev-4.24,1.txz
    pkg add -f https://pkg.freebsd.org/FreeBSD:11:amd64/latest/All/libgpg-error-1.27.txz
    pkg add -f https://pkg.freebsd.org/FreeBSD:11:amd64/latest/All/libgcrypt-1.8.2.txz
    pkg add -f https://pkg.freebsd.org/FreeBSD:11:amd64/latest/All/libxslt-1.1.29_1.txz
    pkg add -f https://pkg.freebsd.org/FreeBSD:11:amd64/latest/All/nspr-4.19.txz
    pkg add -f https://pkg.freebsd.org/FreeBSD:11:amd64/latest/All/nss-3.36.txz
    pkg add -f https://pkg.freebsd.org/FreeBSD:11:amd64/latest/All/xmlsec1-1.2.25.txz
    pkg add -f https://pkg.freebsd.org/FreeBSD:11:amd64/latest/All/oath-toolkit-2.6.2.txz
    pkg add -f https://pkg.freebsd.org/FreeBSD:11:amd64/latest/All/protobuf-3.5.1.1.txz
    pkg add -f https://pkg.freebsd.org/FreeBSD:11:amd64/latest/All/protobuf-c-1.3.0_1.txz
    pkg add -f https://pkg.freebsd.org/FreeBSD:11:amd64/latest/All/ocserv-0.11.11.txz
 

 - Replace "/usr/local/etc/ocserv/conf" with the updated config from https://gitlab.com/ocserv/ocserv/blob/master/doc/sample.config
   Make changes accordingly and make sure that you enable connect-script as follow:

Code: [Select]
   
   connect-script = /usr/local/etc/ocserv/ocserv-script
   

 - Download connect script from https://gitlab.com/ocserv/ocserv/blob/master/doc/scripts/ocserv-script and place it into /usr/local/etc/ocserv/ directory.
   Modify it to assign tunX interface to the openvpn group. OpenConnect Server create new tunX interface for every new connected client. Assigning it to the
   openvpn group allow OpenVPN firewall rules to control ocserv VPN connection too.

Code: [Select]
    #!/bin/sh

    if [ "$REASON" = "connect" ];then
        # Assign tunX to openvpn group
        ifconfig $DEVICE group openvpn
        echo "User '$USERNAME' from '$IP_REAL' connected. Local IP is '$IP_REMOTE'"
    else
        echo "User '$USERNAME' from '$IP_REAL' disconnected (in: $STATS_BYTES_IN, out: $STATS_BYTES_OUT, time: $STATS_DURATION)."
    fi

    exit 0

 - Modify /etc/rc.conf.local and enable ocserv service

Code: [Select]
    echo "ocserv_enable=YES" >> /etc/rc.conf.local

After installation I was able to use OpenVPN firewall rules to control access of OpenConnect clients.

Regards,
-Andrew

Title: Re: Testing open connect server ocserv
Post by: mimugmail on March 14, 2018, 06:44:38 am
Thanks! Good idea with the connect-script. I'm talking to the devs of OC to let the if's rename for FreeBSD, but it needs some testing. If you like you can try those patches, then the device name should be configurable:

http://lists.infradead.org/pipermail/openconnect-devel/2018-March/004761.html
Title: Re: Testing open connect server ocserv
Post by: andrewp on March 14, 2018, 08:13:23 am
I was thinking about renaming tunX interfaces, but then found following note regarding OpenConnect server on pfsense (https://blog.dhampir.no/content/pfsense-as-a-cisco-anyconnect-vpn-client-using-openconnect). So I thought that it could cause an issue on OPNsense too.

Quote
About the CAUTION: pfSense will indeed detonate, as you say, on reboot. There will be a missing interface, as the VPN software hasn’t created it yet. This will kick pfSense into the interface assignment part of the setup, which you’ll have to skip out of to continue booting. Since this requires access to the console, I could not use this at the remote site I was deploying it at, since accessing the console, even over the network, would of course require the network to be there in the first place.
Title: Re: Testing open connect server ocserv
Post by: mimugmail on March 14, 2018, 09:15:51 am
It's a bit tricky to stable rename them when the counter always counts up. If I remember correctly Ad did a python script for this. I think it's better to wait until the OC devs will fix this in their software, then we can start with the plugin.
Title: Re: Testing open connect server ocserv
Post by: andrewp on March 16, 2018, 06:37:36 am
With the following setting in the config file

Code: [Select]
connect-script = /usr/local/etc/ocserv/ocserv-script

it should not be a problem to rename tunX interface into something that is recognized by OPNsense. DEVICE is passed as a parameter to the script. See the note from the config.sample:

Code: [Select]
# Script to call when a client connects and obtains an IP.
# The following parameters are passed on the environment.
# REASON, USERNAME, GROUPNAME, DEVICE, IP_REAL (the real IP of the client),
# IP_REAL_LOCAL (the local interface IP the client connected), IP_LOCAL
# (the local IP in the P-t-P connection), IP_REMOTE (the VPN IP of the client),
# IPV6_LOCAL (the IPv6 local address if there are both IPv4 and IPv6
# assigned), IPV6_REMOTE (the IPv6 remote address), IPV6_PREFIX, and
# ID (a unique numeric ID); REASON may be "connect" or "disconnect".
# In addition the following variables OCSERV_ROUTES (the applied routes for this
# client), OCSERV_NO_ROUTES, OCSERV_DNS (the DNS servers for this client),
# will contain a space separated list of routes or DNS servers. A version
# of these variables with the 4 or 6 suffix will contain only the IPv4 or
# IPv6 values.

# The disconnect script will receive the additional values: STATS_BYTES_IN,
# STATS_BYTES_OUT, STATS_DURATION that contain a 64-bit counter of the bytes
# output from the tun device, and the duration of the session in seconds.
Title: Re: Testing open connect server ocserv
Post by: elfrom on April 26, 2018, 10:55:24 am
Apparently an updated version of ocserv has been released

Code: [Select]
* Version 0.12.0 (released 2018-04-22)
- Allow DTLS stream to come from different IP from TLS stream.
  There are situations where internet providers send the UDP
  stream from different IP (#61).
- Increased possibilities of allowed combinations of authentication
  methods (#108).
- Corrected regression since 0.11.8 with OTP authentication (#137).
- Added support for hostname-based virtual hosts, utilizing TLS
  SNI. With that change it is possible to configure multiple servers
  running over the same port (#133).
[b]- Rename the tun device on BSD systems which support SIOCSIFNAME
  ioctl.[/b]
- Correctly handle proxy-protocol's health commands. That eliminates
  few connection drops when proxy protocol is in use.
- Corrected crash on certain cases when proxy protocol is in use (#146).

Does  "- Rename the tun device on BSD systems which support SIOCSIFNAME
  ioctl." solve the issues that are preventing ocserv from functioning on OPNsense?
Title: Re: Testing open connect server ocserv
Post by: mimugmail on April 26, 2018, 12:56:49 pm
Yes, I was in contact with the dev to do this, but I'm not sure if 0.12 will be included in the ports tree ...
Title: Re: Testing open connect server ocserv
Post by: franco on April 26, 2018, 01:32:06 pm
We can update our tree, try to push it to FreeBSD too.
Title: Re: Testing open connect server ocserv
Post by: elfrom on June 15, 2018, 07:55:45 am
I see 0.12.1 has been available on ports for a month.
Testing this has to be a priority of mine for the coming week.
I really hope it can live up to the hype.
Title: Re: Testing open connect server ocserv
Post by: elfrom on July 04, 2018, 04:17:30 pm
In case anybody else is interested...
I have tested the latest version 0.12.1, it now respects the "device = someinterface"-setting in config.
"someinterface" is appended with an incrementing number.

I enabled an openvpn-server with no settings, just to have an interface for firewall rules, then enabled the "connect-script" as per reply #9 in this thread.

For SSL-certificate i used a certificate generated by the Lets Encrypt plugin, everything seems to be working perfectly.
It would be nice if it was implemented as a plugin. I guess it would be possible to use the radius settings already setup in OpnSense then? And backup would be in the normal firewall backup as well.
Title: Re: Testing open connect server ocserv
Post by: Elys on August 12, 2019, 12:35:05 am
Hello, I tested to reproduce your awesome work!

I'm currently using OPNSense 19.7.

First of all I resolved the dependencies and installed them:

 
Code: [Select]
pkg add -f https://pkg.freebsd.org/FreeBSD:11:amd64/latest/All/libunistring-0.9.10_1.txz
pkg add -f https://pkg.freebsd.org/FreeBSD:11:amd64/latest/All/libidn2-2.2.0.txz
pkg add -f https://pkg.freebsd.org/FreeBSD:11:amd64/latest/All/libtasn1-4.14.txz
pkg add -f https://pkg.freebsd.org/FreeBSD:11:amd64/latest/All/p11-kit-0.23.16.1.txz
pkg add -f https://pkg.freebsd.org/FreeBSD:11:amd64/latest/All/gnutls-3.6.9.txz
pkg add -f https://pkg.freebsd.org/FreeBSD:11:amd64/latest/All/libpcl-1.12.txz
pkg add -f https://pkg.freebsd.org/FreeBSD:11:amd64/latest/All/libgpg-error-1.36.txz
pkg add -f https://pkg.freebsd.org/FreeBSD:11:amd64/latest/All/libgcrypt-1.8.4_1.txz
pkg add -f https://pkg.freebsd.org/FreeBSD:11:amd64/latest/All/libltdl-2.4.6.txz
pkg add -f https://pkg.freebsd.org/FreeBSD:11:amd64/latest/All/libxslt-1.1.33.txz
pkg add -f https://pkg.freebsd.org/FreeBSD:11:amd64/latest/All/nspr-4.21.txz
pkg add -f https://pkg.freebsd.org/FreeBSD:11:amd64/latest/All/nss-3.45_1.txz
pkg add -f https://pkg.freebsd.org/FreeBSD:11:amd64/latest/All/xmlsec1-1.2.25.txz
pkg add -f https://pkg.freebsd.org/FreeBSD:11:amd64/latest/All/oath-toolkit-2.6.2.txz
pkg add -f https://pkg.freebsd.org/FreeBSD:11:amd64/latest/All/protobuf-3.9.0,1.txz
pkg add -f https://pkg.freebsd.org/FreeBSD:11:amd64/latest/All/protobuf-c-1.3.2_3.txz
pkg add -f https://pkg.freebsd.org/FreeBSD:11:amd64/latest/All/python36-3.6.9.txz
pkg add -f https://pkg.freebsd.org/FreeBSD:11:amd64/latest/All/talloc-2.2.0.txz
pkg add -f https://pkg.freebsd.org/FreeBSD:11:amd64/latest/All/radcli-1.2.11_1.txz
pkg add -f https://pkg.freebsd.org/FreeBSD:11:amd64/latest/All/ocserv-0.12.4_1.txz

After that I've set up the certificates using the manual a local user using ocpasswd.


Manual: https://ocserv.gitlab.io/www/manual.html

I've also read this ( https://github.com/openwrt/packages/tree/master/net/ocserv ) one and
set up the connect script and the dummy OVPN server instance (+fw rules) according to reply #9 and #18.

My full config: https://pastebin.com/dY9GbPCE

This here is the debug lvl 3 log output.
https://pastebin.com/EFKsAiNQ

I've already set the file perm to 777, made it executeable and change the ownership serveral time but this error come up.
Has anyone an idea about this?
Title: Re: Testing open connect server ocserv
Post by: andrewp on August 20, 2019, 05:55:35 pm
Have you removed lines with "iptables ..." from ocserv-script? OPNsense uses ipfw instead.
Was you able to run ocserv-script interactively from the shell?
Title: Re: Testing open connect server ocserv
Post by: ligand on February 09, 2020, 02:29:44 am
Hi!  Not sure where I'm going wrong.  I followed the instructions to get ocserv installed.  I enabled proxy_arp so that I can use the same IP space as my local LAN for OpenConnect clients.  I was able to get an android phone to work but I can't get my iPhone to work (it worked perfectly when I was using ocserv on OpenWRT). 


Any ideas?

below is my conf file..

### The following directives do not change with server reload.

# User authentication method. To require multiple methods to be
# used for the user to login, add multiple auth directives. The values
# in the 'auth' directive are AND composed (if multiple all must
# succeed).
# Available options: certificate, plain, pam, radius, gssapi.
# Note that authentication methods utilizing passwords cannot be
# combined (e.g., the plain, pam or radius methods).

# certificate:
#  This indicates that all connecting users must present a certificate.
#  The username and user group will be then extracted from it (see
#  cert-user-oid and cert-group-oid). The certificate to be accepted
#  it must be signed by the CA certificate as specified in 'ca-cert' and
#  it must not be listed in the CRL, as specified by the 'crl' option.
#
# pam[gid-min=1000]:
#  This enabled PAM authentication of the user. The gid-min option is used
# by auto-select-group option, in order to select the minimum valid group ID.
#
# plain[passwd=/usr/local/etc/ocserv/ocpasswd,otp=/etc/ocserv/users.otp]
#  The plain option requires specifying a password file which contains
# entries of the following format.
# "username:groupname1,groupname2:encoded-password"
# One entry must be listed per line, and 'ocpasswd' should be used
# to generate password entries. The 'otp' suboption allows one to specify
# an oath password file to be used for one time passwords; the format of
# the file is described in https://code.google.com/p/mod-authn-otp/wiki/UsersFile
#
# radius[config=/etc/radiusclient/radiusclient.conf,groupconfig=true,nas-identifier=name]:
#  The radius option requires specifying freeradius-client configuration
# file. If the groupconfig option is set, then config-per-user/group will be overridden,
# and all configuration will be read from radius. That also includes the
# Acct-Interim-Interval, and Session-Timeout values.
#
# See doc/README-radius.md for the supported radius configuration atributes.
#
# gssapi[keytab=/etc/key.tab,require-local-user-map=true,tgt-freshness-time=900]
#  The gssapi option allows one to use authentication methods supported by GSSAPI,
# such as Kerberos tickets with ocserv. It should be best used as an alternative
# to PAM (i.e., have pam in auth and gssapi in enable-auth), to allow users with
# tickets and without tickets to login. The default value for require-local-user-map
# is true. The 'tgt-freshness-time' if set, it would require the TGT tickets presented
# to have been issued within the provided number of seconds. That option is used to
# restrict logins even if the KDC provides long time TGT tickets.

#auth = "pam"
#auth = "pam[gid-min=1000]"
#auth = "plain[passwd=./sample.passwd,otp=./sample.otp]"
auth = "plain[passwd=/usr/local/etc/ocserv/ocserv.passwd]"
#auth = "certificate"
#auth = "radius[config=/etc/radiusclient/radiusclient.conf,groupconfig=true]"

# Specify alternative authentication methods that are sufficient
# for authentication. That is, if set, any of the methods enabled
# will be sufficient to login, irrespective of the main 'auth' entries.
# When multiple options are present, they are OR composed (any of them
# succeeding allows login).
#enable-auth = "certificate"
#enable-auth = "gssapi"
#enable-auth = "gssapi[keytab=/etc/key.tab,require-local-user-map=true,tgt-freshness-time=900]"

# Accounting methods available:
# radius: can be combined with any authentication method, it provides
#      radius accounting to available users (see also stats-report-time).
#
# pam: can be combined with any authentication method, it provides
#      a validation of the connecting user's name using PAM. It is
#      superfluous to use this method when authentication is already
#      PAM.
#
# Only one accounting method can be specified.
#acct = "radius[config=/etc/radiusclient/radiusclient.conf]"

# Use listen-host to limit to specific IPs or to the IPs of a provided
# hostname.
#listen-host = [IP|HOSTNAME]

# When the server has a dynamic DNS address (that may change),
# should set that to true to ask the client to resolve again on
# reconnects.
listen-host-is-dyndns = true

# TCP and UDP port number
tcp-port = 443
udp-port = 443

# Accept connections using a socket file. It accepts HTTP
# connections (i.e., without SSL/TLS unlike its TCP counterpart),
# and uses it as the primary channel. That option is experimental
# and it has many known issues.
#  * It can only be combined with certificate authentication, when receiving
#    channel information through proxy protocol (see listen-proxy-proto)
#  * It cannot derive any keys needed for the DTLS session (hence no support for dtls-psk)
#  * It cannot enforce the framing of the SSL/TLS packets, and that
#    breaks assumptions held by several openconnect clients.
# This option is not recommended for use, and may be removed
# in the future.
#
#listen-clear-file = /var/run/ocserv-conn.socket

# The user the worker processes will be run as. It should be
# unique (no other services run as this user).
run-as-user = _ocserv
run-as-group = _ocserv

# socket file used for IPC with occtl. You only need to set that,
# if you use more than a single servers.
#occtl-socket-file = /var/run/occtl.socket

# socket file used for server IPC (worker-main), will be appended with .PID
# It must be accessible within the chroot environment (if any), so it is best
# specified relatively to the chroot directory.
socket-file = /var/run/ocserv-socket

# The default server directory. Does not require any devices present.
#chroot-dir = /var/lib/ocserv

# The key and the certificates of the server
# The key may be a file, or any URL supported by GnuTLS (e.g.,
# tpmkey:uuid=xxxxxxx-xxxx-xxxx-xxxx-xxxxxxxx;storage=user
# or pkcs11:object=my-vpn-key;object-type=private)
#
# The server-cert file may contain a single certificate, or
# a sorted certificate chain.
# There may be multiple server-cert and server-key directives,
# but each key should correspond to the preceding certificate.
# The certificate files will be reloaded when changed allowing for in-place
# certificate renewal (they are checked and reloaded periodically;
# a SIGHUP signal to main server will force reload).

#server-cert = /etc/ocserv/server-cert.pem
#server-key = /etc/ocserv/server-key.pem
server-cert = /var/etc/acme-client/certs/5e3f2bd6db9529.57226152/fullchain.pem
server-key = /var/etc/acme-client/keys/5e3f2bd6db9529.57226152/private.key

# Diffie-Hellman parameters. Only needed if for old (pre 3.6.0
# versions of GnuTLS for supporting DHE ciphersuites.
# Can be generated using:
# certtool --generate-dh-params --outfile /etc/ocserv/dh.pem
#dh-params = /etc/ocserv/dh.pem

# In case PKCS #11, TPM or encrypted keys are used the PINs should be available
# in files. The srk-pin-file is applicable to TPM keys only, and is the
# storage root key.
#pin-file = /etc/ocserv/pin.txt
#srk-pin-file = /etc/ocserv/srkpin.txt

# The password or PIN needed to unlock the key in server-key file.
# Only needed if the file is encrypted or a PKCS #11 object. This
# is an alternative method to pin-file.
#key-pin = 1234

# The SRK PIN for TPM.
# This is an alternative method to srk-pin-file.
#srk-pin = 1234

# The Certificate Authority that will be used to verify
# client certificates (public keys) if certificate authentication
# is set.
#ca-cert = /etc/ocserv/ca.pem
#ca-cert = ../tests/certs/ca.pem


### All configuration options below this line are reloaded on a SIGHUP.
### The options above, will remain unchanged. Note however, that the
### server-cert, server-key, dh-params and ca-cert options will be reloaded
### if the provided file changes, on server reload. That allows certificate
### rotation, but requires the server key to remain the same for seamless
### operation. If the server key changes on reload, there may be connection
### failures during the reloading time.


# A banner to be displayed on clients
#banner = "Welcome"

# Limit the number of clients. Unset or set to zero for unlimited.
#max-clients = 1024
max-clients = 16

# Limit the number of identical clients (i.e., users connecting
# multiple times). Unset or set to zero for unlimited.
#max-same-clients = 2

# When the server receives connections from a proxy, like haproxy
# which supports the proxy protocol, set this to obtain the correct
# client addresses. The proxy protocol would then be expected in
# the TCP or UNIX socket (not the UDP one). Although both v1
# and v2 versions of proxy protocol are supported, the v2 version
# is recommended as it is more efficient in parsing.
#listen-proxy-proto = true

# Limit the number of client connections to one every X milliseconds
# (X is the provided value). Set to zero for no limit.
#rate-limit-ms = 100

# Stats report time. The number of seconds after which each
# worker process will report its usage statistics (number of
# bytes transferred etc). This is useful when accounting like
# radius is in use.
#stats-report-time = 360

# Stats reset time. The period of time statistics kept by main/sec-mod
# processes will be reset. These are the statistics shown by cmd
# 'occtl show stats'. For daily: 86400, weekly: 604800
# This is unrelated to stats-report-time.
server-stats-reset-time = 604800

# Keepalive in seconds
keepalive = 32400

# Dead peer detection in seconds.
# Note that when the client is behind a NAT this value
# needs to be short enough to prevent the NAT disassociating
# his UDP session from the port number. Otherwise the client
# could have his UDP connection stalled, for several minutes.
dpd = 90

# Dead peer detection for mobile clients. That needs to
# be higher to prevent such clients being awaken too
# often by the DPD messages, and save battery.
# The mobile clients are distinguished from the header
# 'X-AnyConnect-Identifier-Platform'.
mobile-dpd = 1800

# If using DTLS, and no UDP traffic is received for this
# many seconds, attempt to send future traffic over the TCP
# connection instead, in an attempt to wake up the client
# in the case that there is a NAT and the UDP translation
# was deleted. If this is unset, do not attempt to use this
# recovery mechanism.
switch-to-tcp-timeout = 25

# MTU discovery (DPD must be enabled)
try-mtu-discovery = true

# If you have a certificate from a CA that provides an OCSP
# service you may provide a fresh OCSP status response within
# the TLS handshake. That will prevent the client from connecting
# independently on the OCSP server.
# You can update this response periodically using:
# ocsptool --ask --load-cert=your_cert --load-issuer=your_ca --outfile response
# Make sure that you replace the following file in an atomic way.
#ocsp-response = /etc/ocserv/ocsp.der

# The object identifier that will be used to read the user ID in the client
# certificate. The object identifier should be part of the certificate's DN
# Useful OIDs are:
#  CN = 2.5.4.3, UID = 0.9.2342.19200300.100.1.1, SAN(rfc822name)
cert-user-oid = 0.9.2342.19200300.100.1.1

# The object identifier that will be used to read the user group in the
# client certificate. The object identifier should be part of the certificate's
# DN. If the user may belong to multiple groups, then use multiple such fields
# in the certificate's DN. Useful OIDs are:
#  OU (organizational unit) = 2.5.4.11
#cert-group-oid = 2.5.4.11

# The revocation list of the certificates issued by the 'ca-cert' above.
# See the manual to generate an empty CRL initially. The CRL will be reloaded
# periodically when ocserv detects a change in the file. To force a reload use
# SIGHUP.
#crl = /etc/ocserv/crl.pem

# Uncomment this to enable compression negotiation (LZS, LZ4).
#compression = true

# Set the minimum size under which a packet will not be compressed.
# That is to allow low-latency for VoIP packets. The default size
# is 256 bytes. Modify it if the clients typically use compression
# as well of VoIP with codecs that exceed the default value.
#no-compress-limit = 256

# GnuTLS priority string; note that SSL 3.0 is disabled by default
# as there are no openconnect (and possibly anyconnect clients) using
# that protocol. The string below does not enforce perfect forward
# secrecy, in order to be compatible with legacy clients.
#
# Note that the most performant ciphersuites are the moment are the ones
# involving AES-GCM. These are very fast in x86 and x86-64 hardware, and
# in addition require no padding, thus taking full advantage of the MTU.
# For that to be taken advantage of, the openconnect client must be
# used, and the server must be compiled against GnuTLS 3.2.7 or later.
# Use "gnutls-cli --benchmark-tls-ciphers", to see the performance
# difference with AES_128_CBC_SHA1 (the default for anyconnect clients)
# in your system.

tls-priorities = "NORMAL:%SERVER_PRECEDENCE:%COMPAT:-VERS-SSL3.0"

# More combinations in priority strings are available, check
# http://gnutls.org/manual/html_node/Priority-Strings.html
# E.g., the string below enforces perfect forward secrecy (PFS)
# on the main channel.
#tls-priorities = "NORMAL:%SERVER_PRECEDENCE:%COMPAT:-RSA:-VERS-SSL3.0:-ARCFOUR-128"

# That option requires the established DTLS channel to use the same
# cipher as the primary TLS channel. This cannot be combined with
# listen-clear-file since the ciphersuite information is not available
# in that configuration. Note also, that this option implies that
# dtls-legacy option is false; this option cannot be enforced
# in the legacy/compat protocol.
#match-tls-dtls-ciphers = true

# The time (in seconds) that a client is allowed to stay connected prior
# to authentication
auth-timeout = 240

# The time (in seconds) that a client is allowed to stay idle (no traffic)
# before being disconnected. Unset to disable.
#idle-timeout = 1200

# The time (in seconds) that a client is allowed to stay connected
# Unset to disable. When set a client will be disconnected after being
# continuously connected for this amount of time, and its cookies will
# be invalidated (i.e., re-authentication will be required).
#session-timeout = 86400

# The time (in seconds) that a mobile client is allowed to stay idle (no
# traffic) before being disconnected. Unset to disable.
#mobile-idle-timeout = 2400

# The time (in seconds) that a client is not allowed to reconnect after
# a failed authentication attempt.
min-reauth-time = 300

# Banning clients in ocserv works with a point system. IP addresses
# that get a score over that configured number are banned for
# min-reauth-time seconds. By default a wrong password attempt is 10 points,
# a KKDCP POST is 1 point, and a connection is 1 point. Note that
# due to difference processes being involved the count of points
# will not be real-time precise.
#
# Score banning cannot be reliably used when receiving proxied connections
# locally from an HTTP server (i.e., when listen-clear-file is used).
#
# Set to zero to disable.
max-ban-score = 80

# The time (in seconds) that all score kept for a client is reset.
ban-reset-time = 1200

# In case you'd like to change the default points.
#ban-points-wrong-password = 10
#ban-points-connection = 1
#ban-points-kkdcp = 1

# Cookie timeout (in seconds)
# Once a client is authenticated he's provided a cookie with
# which he can reconnect. That cookie will be invalidated if not
# used within this timeout value. This cookie remains valid, during
# the user's connected time, and after user disconnection it
# remains active for this amount of time. That setting should allow a
# reasonable amount of time for roaming between different networks.
cookie-timeout = 300

# If this is enabled (not recommended) the cookies will stay
# valid even after a user manually disconnects, and until they
# expire. This may improve roaming with some broken clients.
#persistent-cookies = true

# Whether roaming is allowed, i.e., if true a cookie is
# restricted to a single IP address and cannot be re-used
# from a different IP.
deny-roaming = false

# ReKey time (in seconds)
# ocserv will ask the client to refresh keys periodically once
# this amount of seconds is elapsed. Set to zero to disable (note
# that, some clients fail if rekey is disabled).
rekey-time = 172800

# ReKey method
# Valid options: ssl, new-tunnel
#  ssl: Will perform an efficient rehandshake on the channel allowing
#       a seamless connection during rekey.
#  new-tunnel: Will instruct the client to discard and re-establish the channel.
#       Use this option only if the connecting clients have issues with the ssl
#       option.
rekey-method = ssl

# Script to call when a client connects and obtains an IP.
# The following parameters are passed on the environment.
# REASON, VHOST, USERNAME, GROUPNAME, DEVICE, IP_REAL (the real IP of the client),
# IP_REAL_LOCAL (the local interface IP the client connected), IP_LOCAL
# (the local IP in the P-t-P connection), IP_REMOTE (the VPN IP of the client),
# IPV6_LOCAL (the IPv6 local address if there are both IPv4 and IPv6
# assigned), IPV6_REMOTE (the IPv6 remote address), IPV6_PREFIX, and
# ID (a unique numeric ID); REASON may be "connect" or "disconnect".
# In addition the following variables OCSERV_ROUTES (the applied routes for this
# client), OCSERV_NO_ROUTES, OCSERV_DNS (the DNS servers for this client),
# will contain a space separated list of routes or DNS servers. A version
# of these variables with the 4 or 6 suffix will contain only the IPv4 or
# IPv6 values.

# The disconnect script will receive the additional values: STATS_BYTES_IN,
# STATS_BYTES_OUT, STATS_DURATION that contain a 64-bit counter of the bytes
# output from the tun device, and the duration of the session in seconds.

connect-script = /usr/local/etc/ocserv/ocserv-script
#disconnect-script = /usr/bin/myscript

# UTMP
# Register the connected clients to utmp. This will allow viewing
# the connected clients using the command 'who'.
#use-utmp = true

# Whether to enable support for the occtl tool (i.e., either through D-BUS,
# or via a unix socket).
use-occtl = true

# PID file. It can be overridden in the command line.
pid-file = /var/run/ocserv.pid

# Set the protocol-defined priority (SO_PRIORITY) for packets to
# be sent. That is a number from 0 to 6 with 0 being the lowest
# priority. Alternatively this can be used to set the IP Type-
# Of-Service, by setting it to a hexadecimal number (e.g., 0x20).
# This can be set per user/group or globally.
#net-priority = 3

# Set the VPN worker process into a specific cgroup. This is Linux
# specific and can be set per user/group or globally.
#cgroup = "cpuset,cpu:test"

#
# Network settings
#

# The name to use for the tun device
device = vpns

# Whether the generated IPs will be predictable, i.e., IP stays the
# same for the same user when possible.
predictable-ips = true

# The default domain to be advertised
default-domain = example.com

# The pool of addresses that leases will be given from. If the leases
# are given via Radius, or via the explicit-ip? per-user config option then
# these network values should contain a network with at least a single
# address that will remain under the full control of ocserv (that is
# to be able to assign the local part of the tun device address).
# Note that, you could use addresses from a subnet of your LAN network if you
# enable [proxy arp in the LAN interface](http://ocserv.gitlab.io/www/recipes-ocserv-pseudo-bridge.html);
# in that case it is recommended to set ping-leases to true.
#ipv4-network = 192.168.1.0
#ipv4-netmask = 255.255.255.0

# An alternative way of specifying the network:
ipv4-network = 192.168.25.208/28

# The IPv6 subnet that leases will be given from.
#ipv6-network = fda9:4efe:7e3b:03ea::/48

# Specify the size of the network to provide to clients. It is
# generally recommended to provide clients with a /64 network in
# IPv6, but any subnet may be specified. To provide clients only
# with a single IP use the prefix 128.
#ipv6-subnet-prefix = 128
#ipv6-subnet-prefix = 64

# Whether to tunnel all DNS queries via the VPN. This is the default
# when a default route is set.
tunnel-all-dns = true

# The advertized DNS server. Use multiple lines for
# multiple servers.
# dns = fc00::4be0
dns = 192.168.25.1
dns = 8.8.8.8

# The NBNS server (if any)
#nbns = 192.168.1.3

# The domains over which the provided DNS should be used. Use
# multiple lines for multiple domains.
#split-dns = example.com

# Prior to leasing any IP from the pool ping it to verify that
# it is not in use by another (unrelated to this server) host.
# Only set to true, if there can be occupied addresses in the
# IP range for leases.
ping-leases = true

# Use this option to set a link MTU value to the incoming
# connections. Unset to use the default MTU of the TUN device.
# Note that the MTU is negotiated using the value set and the
# value sent by the peer.
#mtu = 1420

# Unset to enable bandwidth restrictions (in bytes/sec). The
# setting here is global, but can also be set per user or per group.
#rx-data-per-sec = 40000
#tx-data-per-sec = 40000

# The number of packets (of MTU size) that are available in
# the output buffer. The default is low to improve latency.
# Setting it higher will improve throughput.
#output-buffer = 10

# Routes to be forwarded to the client. If you need the
# client to forward routes to the server, you may use the
# config-per-user/group or even connect and disconnect scripts.
#
# To set the server as the default gateway for the client just
# comment out all routes from the server, or use the special keyword
# 'default'.

#route = 10.10.10.0/255.255.255.0
#route = 192.168.0.0/255.255.0.0
#route = fef4:db8:1000:1001::/64
route = default

# Subsets of the routes above that will not be routed by
# the server.

#no-route = 192.168.5.0/255.255.255.0

# Note the that following two firewalling options currently are available
# in Linux systems with iptables software.

# If set, the script /usr/local/bin/ocserv-fw will be called to restrict
# the user to its allowed routes and prevent him from accessing
# any other routes. In case of defaultroute, the no-routes are restricted.
# All the routes applied by ocserv can be reverted using /usr/local/bin/ocserv-fw
# --removeall. This option can be set globally or in the per-user configuration.
#restrict-user-to-routes = true

# This option implies restrict-user-to-routes set to true. If set, the
# script /usr/local/bin/ocserv-fw will be called to restrict the user to
# access specific ports in the network. This option can be set globally
# or in the per-user configuration.
#restrict-user-to-ports = "tcp(443), tcp(80), udp(443), sctp(99), tcp(583), icmp(), icmpv6()"

# You could also use negation, i.e., block the user from accessing these ports only.
#restrict-user-to-ports = "!(tcp(443), tcp(80))"

# When set to true, all client's iroutes are made visible to all
# connecting clients except for the ones offering them. This option
# only makes sense if config-per-user is set.
#expose-iroutes = true

# Groups that a client is allowed to select from.
# A client may belong in multiple groups, and in certain use-cases
# it is needed to switch between them. For these cases the client can
# select prior to authentication. Add multiple entries for multiple groups.
# The group may be followed by a user-friendly name in brackets.
#select-group = group1
#select-group = group2[My special group]

# The name of the (virtual) group that if selected it would assign the user
# to its default group.
#default-select-group = DEFAULT

# Instead of specifying manually all the allowed groups, you may instruct
# ocserv to scan all available groups and include the full list.
#auto-select-group = true

# Configuration files that will be applied per user connection or
# per group. Each file name on these directories must match the username
# or the groupname.
# The options allowed in the configuration files are dns, nbns,
#  ipv?-network, ipv4-netmask, rx/tx-per-sec, iroute, route, no-route,
#  explicit-ipv4, explicit-ipv6, net-priority, deny-roaming, no-udp,
#  keepalive, dpd, mobile-dpd, max-same-clients, tunnel-all-dns,
#  restrict-user-to-routes, user-profile, cgroup, stats-report-time,
#  mtu, idle-timeout, mobile-idle-timeout, restrict-user-to-ports,
#  and session-timeout.
#
# Note that the 'iroute' option allows one to add routes on the server
# based on a user or group. The syntax depends on the input accepted
# by the commands route-add-cmd and route-del-cmd (see below). The no-udp
# is a boolean option (e.g., no-udp = true), and will prevent a UDP session
# for that specific user or group. The hostname option will set a
# hostname to override any proposed by the user. Note also, that, any
# routes, no-routes, DNS or NBNS servers present will overwrite the global ones.

#config-per-user = /usr/local/etc/ocserv/config-per-user/
#config-per-group = /usr/local/etc/ocserv/config-per-group/

# When config-per-xxx is specified and there is no group or user that
# matches, then utilize the following configuration.
#default-user-config = /usr/local/etc/ocserv/defaults/user.conf
#default-group-config = /usr/local/etc/ocserv/defaults/group.conf

# The system command to use to setup a route. %{R} will be replaced with the
# route/mask, %{RI} with the route in CIDR format, and %{D} with the (tun) device.
#
# The following example is from linux systems. %{R} should be something
# like 192.168.2.0/255.255.255.0 and %{RI} 192.168.2.0/24 (the argument of iroute).

#route-add-cmd = "ip route add %{R} dev %{D}"
#route-del-cmd = "ip route delete %{R} dev %{D}"

# This option allows one to forward a proxy. The special keywords '%{U}'
# and '%{G}', if present will be replaced by the username and group name.
#proxy-url = http://example.com/
#proxy-url = http://example.com/%{U}/

# This option allows you to specify a URL location where a client can
# post using MS-KKDCP, and the message will be forwarded to the provided
# KDC server. That is a translation URL between HTTP and Kerberos.
# In MIT kerberos you'll need to add in realms:
#   EXAMPLE.COM = {
#     kdc = https://ocserv.example.com/KdcProxy
#     http_anchors = FILE:/etc/ocserv-ca.pem
#   }
# In some distributions the krb5-k5tls plugin of kinit is required.
#
# The following option is available in ocserv, when compiled with GSSAPI support.

#kkdcp = "SERVER-PATH KERBEROS-REALM PROTOCOL@SERVER:PORT"
#kkdcp = "/KdcProxy KERBEROS.REALM udp@127.0.0.1:88"
#kkdcp = "/KdcProxy KERBEROS.REALM tcp@127.0.0.1:88"
#kkdcp = "/KdcProxy KERBEROS.REALM tcp@[::1]:88"

# Client profile xml. This can be used to advertise alternative servers
# to the client. A minimal file can be:
# <?xml version="1.0" encoding="UTF-8"?>
# <AnyConnectProfile xmlns="http://schemas.xmlsoap.org/encoding/" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://schemas.xmlsoap.org/encoding/ AnyConnectProfile.xsd">
#   <ServerList>
#      <HostEntry>
#               <HostName>VPN Server name</HostName>
#               <HostAddress>localhost</HostAddress>
#      </HostEntry>
#   </ServerList>
# </AnyConnectProfile>
#
# Other fields may be used by some of the CISCO clients.
# This file must be accessible from inside the worker's chroot.
# Note that enabling this option is not recommended as it will allow
# the worker processes to open arbitrary files (when isolate-workers is
# set to true).
#user-profile = profile.xml

#
# The following options are for (experimental) AnyConnect client
# compatibility.

# This option will enable the pre-draft-DTLS version of DTLS, and
# will not require clients to present their certificate on every TLS
# connection. It must be set to true to support legacy CISCO clients
# and openconnect clients < 7.08. When set to true, it implies dtls-legacy = true.
cisco-client-compat = true

# This option allows one to disable the DTLS-PSK negotiation (enabled by default).
# The DTLS-PSK negotiation was introduced in ocserv 0.11.5 to deprecate
# the pre-draft-DTLS negotiation inherited from AnyConnect. It allows the
# DTLS channel to negotiate its ciphers and the DTLS protocol version.
#dtls-psk = false

# This option allows one to disable the legacy DTLS negotiation (enabled by default,
# but that may change in the future).
# The legacy DTLS uses a pre-draft version of the DTLS protocol and was
# from AnyConnect protocol. It has several limitations, that are addressed
# by the dtls-psk protocol supported by openconnect 7.08+.
dtls-legacy = true

#Advanced options

# Option to allow sending arbitrary custom headers to the client after
# authentication and prior to VPN tunnel establishment. You shouldn't
# need to use this option normally; if you do and you think that
# this may help others, please send your settings and reason to
# the openconnect mailing list. The special keywords '%{U}'
# and '%{G}', if present will be replaced by the username and group name.
#custom-header = "X-My-Header: hi there"



# An example virtual host with different authentication methods serviced
# by this server.

#[vhost:www.example.com]
#auth = "certificate"

#ca-cert = ../tests/certs/ca.pem

# The certificate set here must include a 'dns_name' corresponding to
# the virtual host name.

#server-cert = ../tests/certs/server-cert-secp521r1.pem
#server-key = ../tests/certs/server-key-secp521r1.pem

#ipv4-network = 192.168.2.0
#ipv4-netmask = 255.255.255.0
#
#cert-user-oid = 0.9.2342.19200300.100.1.1
Title: Re: Testing open connect server ocserv
Post by: ligand on September 29, 2020, 06:10:47 am
Hi Everyone,
Is it okay to run ocserv on the 20.7 build?

Thanks in adavnce