Bug #11642
closedIPSEC mode-cfg exchange refused because of invalid INTERNAL_IP4_NETMASK
0%
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.
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.
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.