Bug #2004: Client Specific Override ->Tunnel Network - pfSense - pfSense bugtracker

Actions

Copy link

Bug #2004

closed

Client Specific Override ->Tunnel Network

Added by W FM about 13 years ago. Updated over 12 years ago.

Status:

Resolved

Priority:

Low

Assignee:

Category:

OpenVPN

Target version:

Start date:

11/09/2011

Due date:

% Done:

Estimated time:

Plus Target Version:

Release Notes:

Affected Version:

2.0

Affected Architecture:

Description

Tunnel Network description says:
This is the virtual network used for private communications between this client and the server expressed using CIDR (eg. 10.0.8.0/24). The first network address is assumed to be the server address and the second network address will be assigned to the client virtual interface.

Apologies if I am reading the above incorrectly however looks like the first address is actually assigned to the ovpn client (not the server/pfsense).

For example
Tunnel network = 10.10.10.9/30
assigns 10.10.10.9 to the client

client log:
add dev tun0 local 10.10.10.9 peer 10.10.10.10

Actions

Copy link

Updated by Jim Pingle about 13 years ago

Status changed from New to Rejected

.9/30 is not a valid subnet definition, which may be influencing the output. Use .8/30

http://doc.pfsense.org/index.php/Why_can%27t_I_ping_some_OpenVPN_adapter_addresses%3F
http://www.openvpn.net/index.php/open-source/faq/77-server/273-qifconfig-poolq-option-use-a-30-subnet-4-private-ip-addresses-per-client-when-used-in-tun-mode.html

Actions

Copy link

Updated by W FM about 13 years ago

.8 shows same result

Tunnel network = 10.10.10.8/30
assigns 10.10.10.9 to the client

client log:
openvpn²⁶⁶⁴: /sbin/ip addr add dev tun0 local 10.10.10.9 peer 10.10.10.10

Actions

Copy link

Updated by Jim Pingle about 13 years ago

Ah, yeah you're right, the parameters to ifconfig-push in the csc file are backwards. It should be the other way to conform with the openvpn standard. I'll commit a fix shortly.

Actions

Copy link