Project

General

Profile

Actions

Regression #13350

closed

SSL/TLS OpenVPN Client fails with ``ifconfig`` error when the IPv4 Tunnel Network is defined

Added by Erik Osterholm over 2 years ago. Updated over 1 year ago.

Status:
Resolved
Priority:
Normal
Assignee:
Category:
OpenVPN
Target version:
Start date:
Due date:
% Done:

100%

Estimated time:
Plus Target Version:
23.05
Release Notes:
Default
Affected Version:
2.7.0
Affected Architecture:

Description

Filing this on behalf of a client.

When an IPv4 Tunnel Network is defined on an OpenVPN Client in pfSense, we get the following error:

Options error: You must define certificate file (--cert) or PKCS#12 file (--pkcs12)

Removing the network, saving, and restarting the service allows the tunnel to come up.

This was reported working at one point.


Related issues

Related to Regression #14268: OpenVPN client fails to start when a tunnel network is specifiedDuplicate

Actions
Has duplicate Bug #14361: pfSense writes erroneous tunnel network in OpenVPN client configuration despite being provided a valid tunnel networkDuplicate

Actions
Actions #1

Updated by Marcos M over 2 years ago

  • Tracker changed from Bug to Regression
  • Project changed from pfSense Plus to pfSense
  • Category changed from OpenVPN to OpenVPN
  • Affected Plus Version deleted (22.05)
  • Affected Version set to 2.7.0
Actions #2

Updated by Jim Pingle over 2 years ago

  • Assignee set to Jim Pingle

Normally in SSL/TLS with a client/server setup that has multiple clients the clients would never populate the tunnel network. If they need a static address the client wouldn't set it, it would be set in the override on the server side.

I'll have to check what might have changed here, but it probably wasn't a valid configuration before and was somehow given a pass. The only time that's typically valid is when both client and server are set to a /30 tunnel network and that's handled as a special case.

I suspect the difference might be from what changed in #11416 but I'll have to investigate.

Actions #3

Updated by Erik Osterholm over 2 years ago

Does it make sense to remove this GUI element from the options then?

Actions #4

Updated by Jim Pingle over 2 years ago

No, because there are valid cases where it should be set (e.g. to /30) at least for the time being. Since the client settings page can't know how the server is configured it can't validate that on its own so the burden has to be on the user to match what the server expects.

Eventually OpenVPN is removing that mode upstream but for now it's still valid.

Actions #5

Updated by Jim Pingle over 1 year ago

  • Related to Regression #14268: OpenVPN client fails to start when a tunnel network is specified added
Actions #6

Updated by Jim Pingle over 1 year ago

There are more errors from this same case over on #14268 -- but this appears to be with DCO where the errors on #14268 were with DCO disabled. In both cases, however, it was having the tunnel network defined that led to the errors.

Actions #7

Updated by Jim Pingle over 1 year ago

  • Target version set to 2.7.0
  • Plus Target Version set to 23.05

When adding a tunnel network it makes a couple changes to the config, notably it removes the pull directive, it adds topology subnet as chosen in the GUI settings, and then it inserts an ifconfig directive, e.g. when the TN is set to 10.34.51.0/24 the config gets:

ifconfig 10.34.51.2 10.34.51.1

The problem is that syntax is only valid in p2p/net30 mode, not for subnet topology. For subnet topology that should be:

ifconfig 10.34.51.2 255.255.255.0

The actual error in the OpenVPN log is this:

Apr 13 19:40:10     openvpn     3328     /sbin/ifconfig ovpnc1 10.34.51.2/-1 mtu 1500 up 

Note that it has interpreted the second address as a "mask" of -1.

At the very least it should be detecting this case and using the correct ifconfig syntax based on the chosen topology.

The GUI text for the tunnel network should also warn more explicitly about the consequences of specifying a tunnel network on the client and why the user probably doesn't want to do that.

Actions #8

Updated by Jim Pingle over 1 year ago

  • Status changed from New to In Progress
Actions #9

Updated by Jim Pingle over 1 year ago

  • Status changed from In Progress to Feedback
  • % Done changed from 0 to 100
Actions #10

Updated by Jim Pingle over 1 year ago

When testing I checked a variety of different mode/TN combinations and they all had the correct syntax now, for example:

  • SSL/TLS tun with /24 TN - Subnet topology
  • SSL/TLS tun with /24 TN - net30 topology
  • SSL/TLS tun with /30 TN
  • SSL/TLS tap with /24 TN
  • SSL/TLS tap with no TN
  • SK with /30 TN

I also updated the option text in the GUI a bit to hopefully make the behavior more clear.

Actions #11

Updated by Georgiy Tyutyunnik over 1 year ago

tested on:
Version 23.01-RELEASE (amd64)
built on Fri Feb 10 20:06:33 UTC 2023
FreeBSD 14.0-CURRENT

patch fixes the issue

Actions #12

Updated by Jim Pingle over 1 year ago

  • Status changed from Feedback to Resolved
Actions #13

Updated by Jim Pingle over 1 year ago

  • Subject changed from Client OpenVPN error when tunnel is specified to SSL/TLS OpenVPN Client fails with ``ifconfig`` error when the IPv4 Tunnel Network is defined

Updating subject for release notes.

Actions #14

Updated by Marcos M over 1 year ago

  • Has duplicate Bug #14361: pfSense writes erroneous tunnel network in OpenVPN client configuration despite being provided a valid tunnel network added
Actions

Also available in: Atom PDF