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.