Testing open connect server ocserv

[emfabox]

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!

[mimugmail]

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

[emfabox]

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

[mimugmail]

No, havent played with ocserv yet since compilation crashed last time I test it.

[emfabox]

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


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

[mimugmail]

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?

[emfabox]

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

[bobbythomas]

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

[mimugmail]

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 :)

[andrewp]

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 Expand


    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 Expand

   
   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 Expand


    #!/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 Expand


    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

[mimugmail]

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

[andrewp]

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.

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.

[mimugmail]

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.

[andrewp]

With the following setting in the config file

Code Select Expand


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 Expand


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


[elfrom]

Apparently an updated version of ocserv has been released

Code Select Expand

* 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?