Project

General

Profile

Actions

Bug #4526

closed

Incorrect subnet is calculated for proxy server on WAN with "Allow users on interface"

Added by Dmitriy K about 9 years ago. Updated over 8 years ago.

Status:
Resolved
Priority:
Normal
Assignee:
-
Category:
Squid
Target version:
-
Start date:
03/17/2015
Due date:
% Done:

0%

Estimated time:
Plus Target Version:
Affected Version:
All
Affected Plus Version:
Affected Architecture:

Description

steps to rep:
1. WAN IP is a non-RFC1918 IP;
2. Proxy server is on WAN;
3. "Allow users on interface" checkbox is checked;

This will cause proxy stop working and logs will contain:
php-fpm[24532]: /pkg_edit.php: The command '/usr/pbi/squid-amd64/sbin/squid -k reconfigure -f /usr/pbi/squid-amd64/local/etc/squid/squid.conf' returned exit code '1', the output was '2015/03/17 19:07:48| aclParseIpData: unknown netmask '0.91519559599079' in '80.64.24.129/0.91519559599079' FATAL: Bungled /usr/pbi/squid-amd64/local/etc/squid/squid.conf line 25: acl localnet src 80.64.24.129/0.91519559599079 Squid Cache (Version 3.4.10): Terminated abnormally. CPU Usage: 0.037 seconds = 0.030 user + 0.007 sys Maximum Resident Size: 47680 KB Page faults with physical i/o: 0'

Squid 3.4.10_2 pkg 0.2.6 @ pfSense 2.2 x64;

Checkbox description is not fair either:
If this field is checked, the users connected to the interface selected in the 'Proxy interface' field will be allowed to use the proxy, i.e., there will be no need to add the interface's subnet to the list of allowed subnets. This is just a shortcut.

It should be something like that:
Automatically allow access for selected proxy interfaces subnets

Actions #1

Updated by Chris Buechler over 8 years ago

  • Affected Version changed from 2.2 to All
Actions #2

Updated by Kill Bill over 8 years ago

It's not that invalid subnet is calculated, it's that you HAVE invalid subnet on your WAN. This should be validated in pfSense core in the first place, not in Squid package.

Relevant code: https://github.com/pfsense/pfsense-packages/blob/master/config/squid3/34/squid.inc#L1220

Actions #3

Updated by Kill Bill over 8 years ago

https://github.com/pfsense/pfsense-packages/pull/1181 - this will simply ignore invalid subnets and omit those from the ACL.

Actions #4

Updated by Chris Buechler over 8 years ago

  • Status changed from New to Resolved

Merged, thanks doktornotor.

how would the subnet be invalid in a way that you end up with a non-integer? That's not clear at a glance.

Actions #5

Updated by Kill Bill over 8 years ago

. .: That whacky code is widely used as a way to convert long netmask to CIDR. Couldn't make this produce non-integer on anything but obviously broken configurations, like when you stick 255.255.255.253 into netmask and similar. Here's something I used in another package for validation - try to break it with legit IPv4 configs. :)

if ($post['allowedhttpinfohost'] && is_ipaddrv4($post['allowedhttpinfohost']) && $post['allowedhttpinfosubnet'] && is_ipaddrv4($post['allowedhttpinfosubnet'])) {
    $cidr = 32 - log((ip2long($post['allowedhttpinfosubnet']) ^ ip2long('255.255.255.255')) + 1, 2);
    $acl = "{$post['allowedhttpinfohost']}/{$cidr}";
    if (!is_subnetv4($acl)) {
        $input_errors[] = "'{$post['allowedhttpinfohost']}/{$post['allowedhttpinfosubnet']}' is not a valid IPv4 subnet.";
    }
}

AFAICT the OP is getting some shit handed out by ISP via DHCP, or the pfSense validation sucks.

Actions #6

Updated by Kill Bill over 8 years ago

Just for completeness sake - that checkbox uses interface configuration obtained straight from interface configuration via standard pfSense functions (so, really no way to do input validations there, there's no user input for this):

https://github.com/pfsense/pfsense-packages/blob/master/config/squid3/34/squid.inc#L90

Actions #7

Updated by Dmitriy K over 8 years ago

Chris Buechler wrote:

how would the subnet be invalid in a way that you end up with a non-integer? That's not clear at a glance.

Just binded squid on WAN iface with static "white" ip (82.208.xxx.xxx) with a 255.255.255.255 mask (via PPPoE) with the option in subject.

Kill Bill worte:

AFAICT the OP is getting some shit handed out by ISP via DHCP

Nope, everything is fine there.

Actions #8

Updated by Kill Bill over 8 years ago

May I ask what useful outcome did you expect from that? It would allow access, hmmm... lets see, from nowhere but WAN itself. I.e., from no clients. Beyond that:

$iface = array('80.64.24.129', '255.255.255.255');
list($ip, $mask) = $iface;
$ip = long2ip(ip2long($ip) & ip2long($mask));
$mask = 32 - log((ip2long($mask) ^ ip2long('255.255.255.255')) +1, 2);
echo "IP: $ip\n";
echo "Netmask: $mask\n";

Result:

IP: 80.64.24.129
Netmask: 32

Where does it produce the crap you posted in the OP?

Actions #9

Updated by Kill Bill over 8 years ago

Just tried on a box with PPPoE WAN, emulating exactly what Squid package is doing:

$iface = "wan";
$iface = array(get_interface_ip($iface), gen_subnet_mask(get_interface_subnet($iface)));
list($ip, $mask) = $iface;
$ip = long2ip(ip2long($ip) & ip2long($mask));
$mask = 32 - log((ip2long($mask) ^ ip2long('255.255.255.255')) +1, 2);
$src .= " $ip/$mask";
echo "$src";

Result:

 85.70.xxx.xxx/32

Interface configuration:

$ ifconfig pppoe0
pppoe0: flags=89d1<UP,POINTOPOINT,RUNNING,NOARP,PROMISC,SIMPLEX,MULTICAST> metric 0 mtu 1492
        inet6 fe80::71d6:427:600d:fa1c%pppoe0 prefixlen 64 scopeid 0x7
        inet 85.70.xxx.xxx --> 88.103.200.44 netmask 0xffffffff
        nd6 options=21<PERFORMNUD,AUTO_LINKLOCAL>

Sorry, you have broken configuration somewhere, which has nothing to do with Squid package. That said, this will be ignored from 0.4.4 on so checking the box will add nothing to the ACL when the result is invalid.

Actions #10

Updated by Dmitriy K over 8 years ago

I don't think so.
$ ifconfig pppoe0
pppoe0: flags=88d1<UP,POINTOPOINT,RUNNING,NOARP,SIMPLEX,MULTICAST> metric 0 mtu 1492
inet 82.208.x.y --> 78.40.189.1 netmask 0xffffffff
inet6 fe80::ec4:7aff:fe30:e250%pppoe0 prefixlen 64 scopeid 0xc
nd6 options=21<PERFORMNUD,AUTO_LINKLOCAL>

I don't even know where squid took this address (80.64.24.129) from. My provider doesn't have such IP pool.

May I ask what useful outcome did you expect from that?

Maybe because "Allow users on interface" was "on" by default? As a new user of squid package I had no idea about "what does Allow users on interface do". I just picked WAN and got error.

Actions #11

Updated by Kill Bill over 8 years ago

I got it from your original log in your original post.

 Bungled /usr/pbi/squid-amd64/local/etc/squid/squid.conf line 25: acl localnet src 80.64.24.129/0.91519559599079

P.S. People normally do NOT run open proxies on the WAN interface of their firewall box. Ugh.

Actions #12

Updated by Dmitriy K over 8 years ago

Who said it's open? ACLs are set as needed. I repeat myself again: the checkbox was checked on by default. That's all.

Actions #13

Updated by Kill Bill over 8 years ago

ACLs? Like, in Squid? Must be a joke, seriously. So, I assume that 80.64.24.129/unknown_something is something you did put in there manually and this bug never existed as described, pretty much.

Unless you have a problem with ticking that checkbox with 0.4.4, kindly move further absurd discussion to the forums. This is an issue tracker, not a chat.

Actions

Also available in: Atom PDF