Messages

Hello Shayoo,

please tell me your solution for OTP change by users.

With privilege "page-system-usermanager-passwordmg" I get in 25.1.6 an OTP button, but not in 25.4.

Until 24.1.10 the unix groups were properly populated. Now it seems they are pupolated rarely with e.g. logged in users.
But some programms like /usr/local/libexec/squid/ext_unix_group_acl rely on full managed groups.

Is it possible to get the file full in sync with the GUI again?

I had a working DCO instance. After Upgrade 24.7.12 -> 25.1 the connection is established, but no traffic. Regular reconnects due to keepalive parameter.

Even pings to the serverside IP of the tunnel get no answers. Similar to Ticket #8178, but without clustering.

Client is openVPN 2.6.13 on windows (which worked with opnSense 24.7.12).

I configured a new openVPN instance with DCO on a 24.7.9_1 test system. After all tests I configured the same vpn instance on our productive 24.10.1 cluster. Client can connect, but there is no data traffic and the client reconnect after ping-restart timeout.

Further tests:
* Switching to TUN on client/server works
* changeing the server IP in the client config to the WAN IP of the active node works (with DCO)
* changeing the server IP in the client config to the Cluster IP of the active node fails as described above (with DCO)

I see ACK network pakets from the servers the client tries to connect in the opnSense firewall, but it seems they don't leave the server through the data tunnel.

Has someone a working DCO configuration in a Cluster?
Some other hints?

There is a [pull request](https://github.com/opnsense/plugins/pull/3667) using the solution from @chatmate

I opened an [Issue][https://github.com/opnsense/core/issues/7007]

There is an update in 23.7.8 to c-icap 0.5.11.

Starting in debug mode:  c-icap -f //usr/local/etc/c-icap/c-icap.conf -N -D -d 9
...
Adding to acl AUTH the data *
In search specs list 0x0,name AUTH
New ACL with name:AUTH and  ACL Type: auth
Creating new access entry as allow with specs:
In search specs list 0x829c62480,name AUTH
Checking name:AUTH with specname AUTH
In search specs list 0x829c62480,name AUTH
Checking name:AUTH with specname AUTH
        Added acl spec: AUTH
In search specs list 0x829c62480,name 127.0.0.1
Checking name:127.0.0.1 with specname AUTH
In search specs list 0x829c62480,name 127.0.0.1
Checking name:127.0.0.1 with specname AUTH
The acl spec 127.0.0.1 does not exists!
The required acl spec '127.0.0.1' is missing
Fatal error while parsing config file: "//usr/local/etc/c-icap/c-icap.conf" line: 18
The line is: icap_access allow AUTH 127.0.0.1
...

With the mentioned line commented out the service starts.
"127.0.0.1" is not from configuration GUI - so this line is from standard config.

After cloning a 22.7.6 system again and direct upgrade to 22.7.7_1 IPv6 works as expected.

Solved: there is a new setting

System / Settings / Administration : User OTP seed

I test the update on a copy of another system with different IPs.
I changed ovpn-linkup according to the hotfix and restarted the ovpn server.
Interface and routing looks the same on both systems. Here the updated version:

# ifconfig ovpns1
ovpns1: flags=8151<UP,POINTOPOINT,RUNNING,PROMISC,MULTICAST> metric 0 mtu 1500
        options=80000<LINKSTATE>
        inet6 fe80::70f9:5bf:be20:a07a%ovpns1 prefixlen 64 scopeid 0x7
        inet6 fd00:0:ac:d1::1 prefixlen 64
        inet 172.16.38.1 --> 172.16.38.2 netmask 0xffffff00
        groups: tun openvpn
        nd6 options=21<PERFORMNUD,AUTO_LINKLOCAL>
        Opened by PID 41745
# route -n6 show fd00:0:ac:d1::1
   route to: fd00:0:ac:d1::1
destination: fd00:0:ac:d1::1
        fib: 0
  interface: lo0
      flags: <UP,HOST,DONE,STATIC,PINNED>
recvpipe  sendpipe  ssthresh  rtt,msec    mtu        weight    expire
       0         0         0         0     16384         1         0
# route -n6 show fd00:0:ac:d1::125
   route to: fd00:0:ac:d1::125
destination: fd00:0:ac:d1::
       mask: ffff:ffff:ffff:ffff::
        fib: 0
  interface: ovpns1
      flags: <UP,DONE,PINNED>
recvpipe  sendpipe  ssthresh  rtt,msec    mtu        weight    expire
       0         0         0         0      1500         1         0
# tcpdump -ni ovpns1 ip6
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on ovpns1, link-type NULL (BSD loopback), capture size 262144 bytes
09:53:02.526654 IP6 fd00:0:ac:d1::125 > fd00:0:ac:d1::1: ICMP6, echo request, seq 44, length 40
09:53:07.140131 IP6 fd00:0:ac:d1::125 > fd00:0:ac:d1::1: ICMP6, echo request, seq 45, length 40
09:53:12.135485 IP6 fd00:0:ac:d1::125 > fd00:0:ac:d1::1: ICMP6, echo request, seq 46, length 40
^C

So traffic from the client arrives but is not answered.

Also tested applying the hotfix and rebooting.

After upgrade the client gets an IPv6 address as before but cannot connect over IPv6.

We use password + OTP for openVPN connection. Our user have an OTP app on their smartphone. To create a new seed we have all user in a group with this assigned privileges:

Type    Name
GUI    Diagnostics: Authentication
GUI    System: User Password Manager

First is to test the login after creating the OTP seed, allowed by the second privilege.

I don't know the last working version but in 22.7.6 and 22.7.7 the passord manager page has no OTP generator button.
The business version 22.4.3 offers the OTP generation.

Is there a new privilege we have to grant for this?
Will it also disappear after upgrading the business version?
Some workaround?

Due to the release notes for 22.7 this extension is no longer available. Does anybody know an alerantive or a workaround for this?

I imported the configuration in a fresh installed 2.1.10 with cluster IPs deleted.
On this system NAT works.

I use a Cluster as VPN Gateway. The master is a Business Ed. and the backup system is a CE.
After Upgrade access to DMZ/Internet from VPN or LAN arrived the DMZ with the private sender address (no NAT).
I used "manuell NAT" to the cluster IP, but also tried "automatic NAT".
Switching to the backup system with same Problem. Backup system was not activated with 22.1.9 - I assume the problem is also in this version as 22.4.2 is based on it.
Restoring 22.1.8_1 to get the backup system working again.

Is there some known changes that interfere with NAT?