Project

General

Profile

Actions

Bug #11642

closed

IPSEC mode-cfg exchange refused because of invalid INTERNAL_IP4_NETMASK

Added by Sietse van Zanen over 3 years ago. Updated over 3 years ago.

Status:
Duplicate
Priority:
Normal
Assignee:
-
Category:
IPsec
Target version:
-
Start date:
03/10/2021
Due date:
% Done:

0%

Estimated time:
Plus Target Version:
Release Notes:
Affected Version:
2.5.x
Affected Architecture:
All

Description

Some clients, Forticlient is one, will reject the mode-cfg exchange as offered by pfSense.
This is because there is no valid INTERNAL_IP4_NETMASK offered.
pfSense does not allow configuration of this attribute and hence offers the default (0.0.0.0).
This is not a valid netmask and therefore picky clients will reject the entire mode-cfg and log something like: "Unable to acquire valid IP address."

Invalid swanctl.conf pool (under IPv6 /0 netmask is valid, so this is accepted):
pools {
mobile-pool-v4 : mobile-pool {
addrs = 10.0.23.0/24
subnet = 0.0.0.0/0
split_include = 0.0.0.0/0
}
mobile-pool-v6 : mobile-pool {
addrs = ....:....:5a:b412::/64
subnet = ::/0
split_include = ::/0
}
}

Following configuration works fine:
mobile-pool-v4 : mobile-pool {
addrs = 10.0.23.0/24
subnet = 0.0.0.0/0
netmask = 255.255.255.255
split_include = 0.0.0.0/0
}

I would suggest to fix this by explicitly setting the netmask to /32 in mobile ipv4 pools from ipsec.inc, or better yet make it configurable:
if (!empty($a_client['pool_address'])) {
$scconf['pools']['mobile-pool-v4 : mobile-pool'] = array();
$v4pool =& $scconf['pools']['mobile-pool-v4 : mobile-pool'];
$v4pool['addrs'] = "{$a_client['pool_address']}/{$a_client['pool_netbits']}";
if (!empty($net_list4)) {
$v4pool['subnet'] = implode(",", $net_list4);
$v4pool['netmask'] = "255.255.255.255";
$v4pool['split_include'] = implode(",", $net_list4);
unset($net_list4);
}
}

I am willing to open up a PR for the above minor change.

Actions #1

Updated by Viktor Gurov over 3 years ago

#11539 seems related

Actions #2

Updated by Jim Pingle over 3 years ago

  • Status changed from New to Duplicate

Yeah that seems like the same thing to me. Though it's redundant to send clients a network list if that network list is 0.0.0.0/0 -- clients default to sending all, so in all cases I'm aware of, that would have no net effect.

Actions #3

Updated by Sietse van Zanen over 3 years ago

Jim Pingle wrote:

Yeah that seems like the same thing to me. Though it's redundant to send clients a network list if that network list is 0.0.0.0/0 -- clients default to sending all, so in all cases I'm aware of, that would have no net effect.

indeed, below also works fine.
mobile-pool-v4 : mobile-pool {
addrs = 10.0.23.0/24
subnet = 0.0.0.0/0

The following however does not:
mobile-pool-v4 : mobile-pool {
addrs = 10.0.23.0/24
split_include = 0.0.0.0/0

Adding an explicitly valid subnet mask works in any case:
mobile-pool-v4 : mobile-pool {
addrs = 10.0.23.0/24
netmask = 255.255.255.0
split_include = 0.0.0.0/0
}

IE adding the subnet mask as specified in the pool, or just setting it to /32 seems a simple enough fix here.

Actions

Also available in: Atom PDF