In regards to the version of Squiq, I was under the impression that you where running: 'Squid 2.3.4-1', so that is not the issue.
I hate to say this but I now have squid running, snort, fail2ban and not having your problem though I am running my vm's on a ESXI platform if that makes any differences?
I have checked for the NETWORKING environment variable that you mention and I do not have it. Similar configuration to yours:
My suggestion would be to attempt to find the conflicting services, I would disable snort from starting and see if that helps? I do not see fail2ban in your logs but I would also disable it if you have it installed?
Nick would be better at this then I am but sounds like multiple process are attempting to alter your iptables rules at the same time, could be Squid?
The squid starting information is going to be in the message... log, though I do not know if that will tell us much. Maybe the start time of Squid will be that same as your error?
I noticed that the current version of squid in the repos is:
[root@cognoquest ~]# yum list squid
You could take a look at your startup script for Squid? See if it similar to this:
Also can you duplicate your vm's with another vlan? and test with a more recent version of squid?
Sorry, I may have misunderstood your problem. I was under the impression that your second VM was attempting to access your Gateway VM prior to it being operational.
You may be running into hardware contention issues which in you case creating a racing situation? I have read that it is not recommended to run a Gateway as VM's, mostly because of clock issues but who knows what else? I am as culprit as you are, I also run my home gateway from a VM though I do not use Dropbox and Squid.
You may have to experiment and delay the start of Squid? or maybe you can try this fix: Title This solution is for another problem and a bit of a shot in the dark but I recently discovered that I was having a conflict with the start of the firewall and fail2ban.
content of: clearos-sshd.conf
content of: clearos-sshd-ddos.conf
Straight after boot up, result of "lsmod | grep ip_set":
Straight after /usr/bin/fail2ban-client reload, result of "lsmod | grep ip_set":
I think the bug you are referring to was that both the above jails actions where identified by the same name in the configuration. This would mess up the iptables: [name=sshd] but also note that they where using a different action at the time: iptables-allports[name=sshd] this was replaced by: iptables-ipset-proto6-allports[...]
Wanted to check if any one else is having this issue, I am working on enhancing my mail gateway fail2ban jail scripts and encountered an issue with a rule missing. I do not think it is related to my changes but you never know.
I boot my server, I have 6 jail configuration.
Output of iptables: (notice: --match-set f2b-sshd missing)
I reload: fail2ban-client
Output of iptables: (notice: --match-set f2b-sshd can now be found)
It appears to me that this occurs when we use the fail2ban action: iptables-ipset-proto6-allports in multiple jail activities such as: clearos-sshd.conf & clearos-sshd-ddos.conf
Anyone else noticed this problem?
I can not find anything about Chrome requirements for Certificate requiring Subject Alternate Names only? Now indeed I think SAN where introduced part of the X.509 V3 certificates specifications but is it a requirement for Chrome?
The issue with creating self-signed certificates using the Webconfig ClearOS app for Chrome could be entirely another problem. I think I also tried to use the app but at the time it was creating X.509 V1 certificates that I had to manually change to be V3, this might not be the case anymore.
This is certainly a complicated subject and I am no expert. Looking at 'Taryck BENSIALI' configuration, a Wildcard DNS within a Subject Alternate Names (SANs) is an approach the I never thought of. Also note Wildcard Certificates can be useful but will only secure a specific subdomain level.