I have had some difficulty in getting BT support to understand this but lets have another go, maybe someone at BT will stop trying to find reasons why this should not even be looked at and take another look at it.

I have two HH4 ADSL routers on two separate PSTN lines. Both pretty much configured the same. They both connect to two different interfaces on a single pfSense 2.1 Server both on their respective HH4's DMZ.

Due to many problems with the lines over the last 18 months, I monitor them from a Zabbix server in the Cloud. Just a simple PING to start with. The PING hits the HH4, is passed to the DMZ and so to the pfSense Server with its Firewall configured to allow PINGs. Until a couple of days ago both were PINGing away fine then one stopped. Checking the HH4 logs I found that at the exact time the PINGs started to fail, that particular HH4 had upgraded itself from 4.7.5.1.83.8.130.1.17 to 4.7.5.1.83.8.130.1.26 (at 07:50 am on the 8th of February). Nothing else had been changed.

Rebooting the offending HH4 did not help. Even a complete configuration reset and then reconfiguring the DMZ made no difference. Leaving me with the reasonable conclusion that the new Firmware (which has also introduced IPv6 support, so not a trivial change) has broken the DMZ handling.

The other HH4, on the older Firmware is still running fine while the newer Firmware continues to block DMZ traffic.

Attempts to report this as a Firmware bug via BT Support have fallen on stoney ground. Apparently nobody has reported this issue therefore it does not exist. Great logic.

Event log: Firewall entries...

IN: BLOCK [16] Remote administration (ICMP type 8 code 0 xxx.xxx.xxx.xxx->yyy.yyy.yyy.yyy on ppp0)

ICMP Type 8 is PING, xxx.xxx.xxx.xxx is where I'm PINGing from and yyy.yyy.yyy.yyy is the Public IP for the HH4.

IN: BLOCK [16] Remote administration (TCP [xxx.xxx.xxx.xxx]:54275->[yyy.yyy.yyy.yyy]:22 on ppp0)

When I try ssh to the Public IP of the HH4.

These packets should be forwarded to the DMZ Server but they are getting blocked by the "Remote Administration" filtering rules. Looks like "Remote Administration" filtering is now being done BEFORE DMZ rules. That would be a bad thing!

Oh and if someone from BT Support does read this, PLEASE focus on the Firmware issue and don't tell me that as pfSense is OpenBSD which is a Linux based Operating System, that you don't support it. I'm not asking you to "support" it, just to look at the real problem. Also, you don't need to point me to articles on setting up a DMZ or Port Forwarding, that's not the issue. Thanks.

Go on BT prove me wrong or fix it.

Update - 1st of March - BT continue to scratch their heads over this and my second HH4 has now picked up the new Firmware and has the same problem.

=======

And the answer is....

Sagem have introduced an interesting little "improvement" in the new firmware. If your HH4 uses the internal DHCP Server (as is the default) to hand out the IP address to your DMZ Server then despite the fact that the HH4's own internal DHCP server knows the IP that was handed out, the HH4 now does a DNS lookup based on the host name that your DMZ Server provides during it's DHCP request to get the IP address in the first place, as the DNS host name to find the IP. If your DMZ Server's host name is more that a single level name (has a dot in it), then the HH4 does the DNS lookup back over the Internet via BT's DNS Server, which will never work.

Apparently this is "working as designed" so a work around is needed....

1) Don't use DHCP to get the DMZ IP, use a static IP address.

2) (If your DMZ Server supports this) Only pass a single level host name in the DHCP request.

A short guide to setting up Zabbix to monitor the state of Asterisk SIP Trunks.

A real world implementation of Zabbix Monitoring to help manage a Production Line in a Manufacturing Business.

A while ago, well to be honest two and a half years ago, I built and installed a Factory Floor Information Display System at a client's site (Custom Built Appliance Based Information Display System from CommuniG8 installed at Eltherington Industries). The system is feed with data from two sources. The first is the planned man hours for work to be completed during a shift and is set at the start of the shift. The second is fed acutomatically as completed items come off the Production Line. This information is displayed on a large display screen together with a percentage to show how near completing the shift's planned work they are at any time.

Earlier this year, four more displays where added being fed with data that related to different parts of the Production Line. Zabbix (1.8.3 I know I should be using v2 by now) was also introduced, originally just to monitor the technical metrics on the displays and to check availability. The Zabbix Agents were configured to push data to the Zabbix Server as there was inbound connections were not allowed.

There were then five displays showing data from seven different points on the Production Line. Gathering this data into one central database could offer the opportunity to analyse the flows along the Productions Line. As Zabbix was there collecting system performance and availability data, there was the option to extend this data collection to include metrics from the application itself. A small application change was introduced to save the current values for planned, actual and completed percentage to files. The Zabbix agent was then configured via "User Parameters" to read these files and pass the values back to the Central Zabbix Server. This information could then all be displayed on a Zabbix Map.

(Click to enlarge)

This allowed all the information to be seen in one place and show some checks for anything that might be out of kilter (more than 100% completed for example). Using this map together with the graphing facilities of Zabbix allowed analysis of how completion percentages varied thoughout the Production Shift. However, there was no simple way to show if the completion percentages were in balance along the whole Production Line. If all points on the Production Line are not completing at the same rate then this introduces unwanted delays at some part of the Production Line leading to inefficiantcies. So we needed a display of vertical bars for percentage complete at each point on the Production Line allowing us to easilly see which ones were out of step. Unfortunatly, none of the standard Zabbix Graphs could be setup to do this.

The data was easily avaiable in the "items" table "lastvalue" column. I created a new Zabbix page "workflow.php" (I had to update the "$ZBX_MENU" array in "include/menu.inc.php" so that the new page could be navigated to). The page had to include "include/page_header.php" and "include/page_footer.php" to gie it the Zabbix look and feel. This was all a bit of a hack, so to try to keep things secure a check was added in the new page that the logged on user was either "Admin" or the logon used by my client (by checking "$USER_DETAILS['alias']). A simple database query was used to get the lastvalue for each of the itemids required to get the seven completion percentages. I then used jQuery and jqPlot JavaScript libraries to draw the bar chart.

(Click to enlarge)

This is just one example of how the capabilities of Zabbix can be used as a platform for collecting Application metrics to help analyse a Business Process. It just needs Applications to be developed with instrumentation in mind and a willingness to extend the graphing funtionality of Zabbix. A cleaner approach to this would be to use the Zabbix API to access the data and use an external web site to render the results.

Thanks for reading, Richard Gate.

Any questions? Please e-mail me This email address is being protected from spambots. You need JavaScript enabled to view it.