[Freedombox-discuss] Privoxy no longer working, no networks configured as internal (?)

[Sunil Mohan Adapa]

On 17/12/18 6:23 pm, A. F. Cano wrote:
> hi,
> 
> I suspect this might be caused by the latest upgrade to nftables.
> Firewald refused to upgrade automatically so I did it via aptitude as I
> had done before, keeping the old firewalld.conf.  After checking the
> differences, there were only two:
> 
> $ sudo diff /etc/firewalld/firewalld.conf /etc/firewalld/firewalld.conf.dpkg-dist                                                                   
> 6c6                                                                             
> < DefaultZone=external                                                          
> ---                                                                             
> > DefaultZone=public                                                            
> 64c64                                                                           
> < FirewallBackend=nftables                                                      
> ---                                                                             
> > FirewallBackend=iptables
> 

Debian defaults to DefaultZone=public and FirewallBackend=iptables.
FreedomBox during initial setup changes that to DefaultZone=external and
FirewallBackend=nftables.

Debian momentarily tried to switch to nftables as well and ran into
compatibility issues with libvirt and reverted back until those are
fixed. In FreedomBox, there is no reason to go back to iptables.

The configuration change prompt is nasty and we are looking to avoid that.

> Looks like the new versions still default to iptables.  Should be ok to
> leave the old version, but then privoxy doesn't work.
> 
> Plinth/apps/privoxy says:
> 
> Service Privoxy is not running
> 
> Privoxy is available only on internal networks. 
> Currently there are no network interfaces configured as internal.

Privoxy is only available on internal networks by design because
otherwise, you would be running an open proxy for the Internet.

The proper way to a smooth privoxy experience is to have a network
connection assigned 'internal' firewall zone and machines connected on
that network will be able to access privoxy.

> 
> Maybe some internal default in the firewalld config changed?
> 
> Is this a known issue? Has anyone else encountered this?
> 
> Plinth/sys/networks shows the firewall zone as "Internal" for the
> "Freedombox LAN", so there's some internal inconsistency.
> 
> Any ideas what to check/change?

Recently there were multiple regressions with firewalld[1][2] Debian
package.

On 17/12/18 7:34 pm, A. F. Cano wrote:
> Well, not sure what actually caused this problem, but
>
> sudo /etc/init.d/privoxy restart
>
> seems to have fixed it.
>
> It would still be interesting to know if anyone else has seen
> privoxy stop working.
>

This should not have happened. Perhaps firewalld is not working properly.

Please ensure the following in `firewall-cmd --list-all-zones`:
- Output succeeds meaning that firewalld is running.
- privoxy is one of the services allowed in internal zone.
- Your interface which connects your privoxy clients to FreedomBox is
added to the internal zone.
- FirewallBackend for firewalld is nftables.

On 28/12/18 3:17 pm, A. F. Cano wrote:> Hi,
>
> I'm following up on this old thread because I've encountered another
> problem caused by the nftables/iptables issue.
>
> It was my understanding that FreedomBox now uses nftables, and the old
> config file prior to the upgrade I described below had nftables.
>
> After the latest upgrade (a couple of days ago) something must have
> changed enough that plinth (0.45.0) no longer worked.  I rebooted
> and then the whole FreedomBox became totally inaccessible.  No ssh,
> no plinth, ping said "packet filtered".  All I could do was take the
> SSD card out, mount it on another computer and change the
>
>  FirewallBackend=nftables
>
> to
>
>  FirewallBackend=iptables
>
> After putting the SSD card back and rebooting, everything
> was back to normal.
>
> I leave the old issue below for completeness.
>

From my experience, iptables backend is causing issues[1][2] and
nftables is running smoothly. Please ensure that iptables-restore -V is
showing "iptables v1.8.2 (nf_tables)" and not "iptables v1.8.2
(legacy)". Please also check `journalctl -u firewalld` for errors listed
in the bug.

Links:

1) https://salsa.debian.org/freedombox-team/plinth/issues/1440
2) https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=914694

-- 
Sunil

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: OpenPGP digital signature
URL: <http://alioth-lists.debian.net/pipermail/freedombox-discuss/attachments/20181230/3ac1b7dd/attachment.sig>