Web-Proxy NOT starts itself

IPFire 2.27 (x86_64) - Core Update 160

since some month we watch that after reboot of iPFire-PC the service Web-Proxy is NOT ACTIV. We have to start it manual.
We hoped, that this is gone after an update, but there is no changing.
How we can find the reason ?

Hi, this problem/phenomenon is known since March.
See this topic or my own topic.
How do we escalate this failure to the developers?
Regards, Marc

If you want to ‘escalate’ just go the usual way, open a ticket in bugzilla.

Information to add a bug report in IPFire Bugzilla:

2 Likes

I’ve experienced issue too, but (temporarily) resolved by:

Menu Network > Web Proxy
Untick SquidClamAV, URL filter and Update accelerator (as required)
Press Save and Restart
Tick SquidClamAV, URL filter and Update accelerator (as required)
Press Save and Restart

Have not checked config files before/after, but assume just re-writing correct config(s).

UPDATE - still fails after reboot. Strange as not all my firewalls affected (all 2.27 cu 160)

After investigation of my firewalls, looks like the ones with problems have the wrong PAC file address. They have the Red WAN IP address for the file path, rather than Green LAN address.
Not sure where proxy getting that configuration from.
Menu: Network > Web Proxy, check Open PAC File: http://red-wan-ip-address:81/wpad.dat.

Having said that, some with incorrect address have proxy work after reboot.
Not consistent.

I opened two different files on two different IPFire systems. both look very similar and neither have a Red WAN IP address.

On my test system at menu Network > Web Proxy > check Open PAC File: http://192.168.1.1:81/wpad.dat. This is what I see on my test system:

function FindProxyForURL(url, host)
{
if (
     (isPlainHostName(host)) ||
     (isInNet(host, "127.0.0.1", "255.0.0.0")) ||
     (isInNet(host, "192.168.1.0", "255.255.255.0")) ||
     (isInNet(host, "169.254.0.0", "255.255.0.0"))
   )
     return "DIRECT";

 else

if (
     (isInNet(myIpAddress(), "192.168.1.0", "255.255.255.0"))
   )
     return "PROXY 192.168.1.1:800";
}

Is this what you see? (maybe I opened or looked at the wrong file)

what is this 169.254.0.0 ? I have the same entry. It is not part of my network, why is it there?

What does it mean DIRECT? No proxy?

I also do not have any RED interface in the WPAD file.

This code, I believe, is basically saying don’t use the proxy if the host that the url is one of the following:-

  1. URL that is plain host name without domain name portion
  2. Local Host
  3. Private non-routable IP
  4. Fallback non routable IP assigned to Windows machines if they fail to get a dhcp address

The above basically means a URL that is local and not out on the Internet.

Following link for more info on item 4.
https://packetlife.net/blog/2008/sep/24/169-254-0-0-addresses-explained/

2 Likes

@ipcopmann - Can you send us a copy of your PAC file? (with private info hidden)

ALL my firewalls now showing Red WAN as the address as the path to the PAC file.
PAC files as expected, e.g.:

function FindProxyForURL(url, host)
{
if (
(isPlainHostName(host)) ||
(isInNet(host, “127.0.0.1”, “255.0.0.0”)) ||
(isInNet(host, “Green LAN”, “255.255.255.0”)) ||
(isInNet(host, “Blue LAN”, “255.255.255.0”)) ||
(isInNet(host, “Orange LAN”, “255.255.255.0”)) ||
(isInNet(host, “169.254.0.0”, “255.255.0.0”))
)
return “DIRECT”;

else

if (
(isInNet(myIpAddress(), “Green LAN”, “255.255.255.0”))
)
return “PROXY Green LAN:800”;

else

if (
(isInNet(myIpAddress(), “Blue LAN”, “255.255.255.0”))
)
return “PROXY Blue LAN:800”;
}

On my firewall which had Green LAN as the path to the file, the PAC file was:

function FindProxyForURL(url, host)
{
}

I have unchecked all Common settings and saved, checked service stopped, rechecked Transparent etc. and restarted. PAC file now populated correctly. PAC file path still Green LAN (haven’t rebooted yet).

All my firewall except one are PPPoE, so thought that might be related?

So you are saying that this:

is your Red Wan Address?!?

Correct.
I did edit my original post to clarify.

Wow! That is scary. My quick wild guess is that the RED and GREEN are reversed during setup or cables are reversed.

Hopefully one of the experts will add their comments!


EDIT:

Silly question: How are you accessing the IPFire WebGUI? From the GREEN (or blue) zone? Or some other way?

1 Like

Hi Jon,
You hit the nail on the head!
When accessing from Red, path to file Red WAN, accessing from Green, path to file is Green LAN, from Blue, path is Blue LAN. Doh!
So a red Herring as far as failing to start concerned.

1 Like

This is true!!
It is just because the line is generated by

<td colspan="4">$Lang::tr{'advproxy wpad view pac'}: <a href="http://$ENV{SERVER_ADDR}:81/wpad.dat" target="_blank">http://$ENV{SERVER_ADDR}:81/wpad.dat</a></td>

That means you get the IP address of your ‘native’ interface; green0 IP for LAN clients, blue0 IP for WLAN clients. If you opened your red interface for access to the WebGUI, clients from WAN get the WAN IP of IPFire.

2 Likes

So let’s go back to the scary part… Are you accessing the IPFire WebGUI from RED?

How are you doing this? I always thought this was a bad thing to do.

It is a bad thing, but possible. :innocent: