I’m sure this isn’t a big deal because by the time you get to this complex of a network, you would most likely want to have custom content filter profiles setup for your separate zones, but I added a second green zone:
…and the default profile did not apply to it. I got this error no matter where I browsed:
Until after I added this content filter profile:
Now everything works fine. Just thought I’d bring this to the devs’ attention. 
It seems that only the first green zone is automatically enabled to surf.
I’ll try to reproduce this in the coming days.
No, I have two green zones, and I can surf from each zone without doing anything… With squid and web content filter activated…
Well that’s odd… maybe I should test this on another VM in the morning and see if I see consistent results.
You got me thinking more about this and prompted some more immediate testing that I had not anticipated. 
I came up with the idea that maybe the cause was the order that I setup my NethServer instance. I setup my NS in the following order
I’d be willing to bet you setup yours in the following order:
So it looks like when a zone is added, a step is missing somewhere in NS to reconfigure the default web filter policy.
Please try to reproduce it on a fresh installation.
Please use this template!
Sorry about that @alefattorini. I should have collected more information and done more testing before posting this one.
Title updated to specify more detail.
I believe all of the other information from the template you posted is already in this thread. I’ll be sure and follow that in the future.
Issue filed:
http://dev.nethserver.org/issues/3275
Another bug in QA, @Adam could you check it? /cc @dz00te
http://dev.nethserver.org/issues/3275
Verified this one too! 
Great shot man!
Sorry to ask, can you please verify it again? http://dev.nethserver.org/issues/3275
The fix was added to the wrong package.
That’s odd… Which package was it added to? Would the upgrade nethserver-base command I ran have installed the package that the fix was added to?
Edit: Oh… I see. It should have been the squid package, not base.
@giacomo, I don’t see the following package in the testing repo:
nethserver-squid-1.3.8-1.2.g014d519.ns6.noarch.rpm
The latest one I see is 1.3.8-1.1 from Oct 8th.
I think the rpm is correctly published: http://packages.nethserver.org/nethserver/6.7/testing/x86_64/Packages/nethserver-squid-1.3.8-1.2.g014d519.ns6.noarch.rpm
Try to clean yum cache:
yum --enablerepo=nethserver-testing cleanI see what happened… The base update was in the 6.6 repo. I’ll install 6.7. Thanks!
Edit: I’m getting a conflict error when attempting to upgrade squid package. Am I doing something wrong?
sorry for the little OT
@giacomo I do not see folders
6.7 / testing
6.7 / nethforge-testing
in any of the mirror, including mirror.nethserver.org… it’s normal?
No you’re not, it’s a bug: It seems you’re a bug hunter! 
I will fix it in few minutes…
Yes, it’s normal.
Since the testing repository is transient, it’s not configured to be in sync across mirrors (CentOS does the same).
When a yum client request a package inside the testing repository, it will be always redirect to packages.nethserver.org (see: https://github.com/NethServer/mirrorlist/blob/master/6.7/nethserver.php#L27). This configuration allows all developers to have instant access to all rpms inside the testing repo.
Do you think is a good choice or we should add testing to the mirrors?
Again, it’s not you’re fault.
I didn’t realized that the bad nethserver-base rpm was wrongly published inside the 6.6 branch 
By the way, the 6.6 branch is now frozen and all fixes will be delivered for 6.7.
Thanks for you patience.
That makes me feel better. 
I’ll annoy everyone with notification emails by updating the issue in dev. 
