As another thought, if you don't have the file /etc/dhcp/dhclient.conf, create one, then put in it:I used to do it for a different reason (where the ISP was sending back an invalid DHCP server in the reply), but another user has reported success where he was not getting an IP address at all.

As another thought, if you don't have the file /etc/dhcp/dhclient.conf, create one, then put in it:I used to do it for a different reason (where the ISP was sending back an invalid DHCP server in the reply), but another user has reported success where he was not getting an IP address at all.

I think your rule should be OK because, in effect it is doing the same as the default rule, but higher in the chain. The problem is that GM inserts its rules two places too high for OpenVPN to work with it. It is fixed in the beta.

From your rule I'd simplify it and remove the conntrack bit and the -d bit so it works for all IP's or even simplify it as far as mine.

As I said before, check the OpenVPN docs. There is a GM specific note in the Troubleshooting. If you want to avoid that, you could try the beta version of GM which gets round the problem, but I believe it has some other issues with it.

It doesn't make sense that you should need it. There is already a rule equivalent to:This should entirely cover your rule. Perhaps you have another block in place........ or are you running Gateway Management?

Attack Detector was updared recently IIRC.
You can use the local file but remember the local file fires before all the numbered files, but after the main firewall and custom. Also just changing local will trigger an immediate firewall restart. We do not change the local file.
Alternatively you can add a numbered file. I think the number has to be between 01 and 99, but I am not sure of the exact rules. The number affects where it fires in the firewall starting sequence. The higher the number the later it fires.
Remember to always enclose you rules in an IPv4 block or that the file exits if the firewall is loading IPv6. See how it is done in any of the other files. There seem to be 2 ways. If you don't the rule will fire twice, once during the IPv4 script and once during the IPv6 script. If you specify an IPv4 IP address, the firewall will also show failed if the IPv6 script tries to load it.

An update to app-bandwidth-viewer is now available (or syncing to the mirrors) which should correct the old issue of the time on the graph to displaying in UTC rather than local time.

app-php-engines has now been updated and is syncing to the mirrors for testing. This update adds support for PHP 7.3. When your mirror has sync'd, you can update to it with:

app-php-engines has now been updated and is syncing to the mirrors for testing. This update adds support for PHP 7.3. When your mirror has sync'd, you can update to it with:

Packages being updated to the Community tonight (07/07/2020)

Tonight (07/07/20-08/07/20) the following updated packages are being released:

• 7.8 to Business and Home
  
• app-flexshare - Remove TLSv1.1 support from the web server. Although the patch is in app-flexshare, it affects the webserver. Note that we can't implement the "Intermediate compatibility" list from https://wiki.mozilla.org/Security/Server_Side_TLS as it would cut out the following O/S's:
  


• IE 11 / Win Phone 8.1 R
  
• Safari 6 / iOS 6.0.1
  
• Safari 7 / iOS 7.1 R
  
• Safari 7 / OS X 10.9 R
  
• Safari 8 / iOS 8.4 R
  
• Safari 8 / OS X 10.10 R
  

We have had to keep in some of the lower grade ciphers. We will keep this under review.

* by the package name = the package is also being released to Business at the same time.

Packages available for testing

• webconfig-httpd - I'd like to bring it up to the same upstream version as httpd. Also remove TLSv1.1 support.
  
• clearos-framework - remove webconfig TLSv1.1 support
  
• clearos-devel - update the upstream list, tweak to get mock working again. Thanks to Team Canada.
  
• syswatch - fixing issues noticed by Todd Lewis. He proposed a patch which Peter reviewed and I tweaked. Feedback from anyone with a dynamic IP would be appreciated.
  
• app-dnsthingy - This is the same update as app-gateway-management but also includes a rebranding from DNSThingy to AdamOne. Update with:
  
• app-gateway-management - update with:
  
• adamone - this is the underlying package for the above beta versions of app-gateway-management/app-dnsthingy. If you have either of the above beta's installed, you can update with:Please restart GM afterwards.
  
• app-network - code merge complete. Seems to work for everything except external VLANs and a few quirks.
  


• Now allows you to set up Wireless and Cellular interfaces. You will also need app-wireless to configure a NIC as an access point. Otherwise manual configuration is then needed for WiFi and Cellular devices.
  
• I've tweaked it for kernel mode PPPoE (much faster and lower resources). For the moment we are not forcibly converting PPPoE interfaces over, but if you edit an interface it will switch to kernel mode.
  
• Hides irrelevant interfaces from app-network-report such as docker0, veth* and ifb*.
  
• Numerous other changes since last 2.6.0
  
• Do not use the the update if you use VLAN's on external interfaces.
  

Unless detailed otherwise, packages available for testing can be installed with:

Packages being worked on:

• app-php-engines - add support for PHP 7.3
  
• app-firewall - see if I can do some more bug fixes.
  
• app-attack-detector to add a button beside each banned IP to you can unban it. This was being worked on by an external contributor.
  
• app-network - Two more bugs to go. Team Canada are working on it.
  
• app-qos - see if I can change the webconfig to use the full range of port selections allowed by the multiport rule.
  

Previous updates notice