Hi, I have installed 18.06.0 on a BT HH5A, which was moderately painless. However, I cannot make it connect to the VDSL. I have BT's "professional" broadband, and a block of 8 (or 5) static IPs.
BT's Professional broadband means you have a dedicated name and password for the PPP.
With 17.04, I had to create ptm0.101 and configured that. It worked - it is still working, but I accidentally locked out my ssh access with the firewall. (It is a different HH5A).
With 18.06.0, I get "USER_ERROR" (Sometimes, often nothing) If I don't configure the ptm0.101, then it does not work.
Also, I find it very hard to understand the firewall. I can follow the instructions if they do what I want, but they mostly don't. Without understanding, I can't make reasonable guesses. I have a DMZ with my servers on the yellow sockets (labelled LAN to confuse) and all my LAN on the red socket labelled "WAN" or wireless. I want stuff from the WAN (ie DSL) to go strait to the servers (DMZ) if they are in my static IP block, unmolested, and stuff from LAN to go to the WAN or DMZ as appropriate, but NATted. Stuff from the servers goes out to DSL, but not to the LAN (unless it is a reply to a request via NAT).
There appear to be various places where you set INPUT, OUTPUT or FORWARD, but I am not sure how they are handled, nor where I should tick the NAT box, and where not.
Thanks. Yes, this fixed the WAN issue on my BT HH5A. I now have a different problem:
I have a DMZ with servers on it (using some of the GBE ports). The servers sit in a block of public IP addresses. I have configured the firewall to the best of my understanding.
The outside world can access my servers.
AFAICT, the servers can access the outside world (which is needed)
The LAN can access the outside world.
To my enormous embarasment, the LAN can't access the servers.
I am using LuCI to configure. I have input, output and forwarding all accept, everywhere,
and masking and MSS clamping enabled on LAN to (WAN and DMZ).
Please help me!
Incidentally, I have three HH5As and two HH5Bs. All of them flake out if the ambient temperature reaches 30C, and some of them if it reaches 25C. I believe this does not happen if you disable the wirelesses, but have not done proper scientific tests.
I originally thought this was BT's flakey firmware. There is no evidence that their firmware is not flakey, but the hardware is definitely best kept in a cool place, not a cupboard full of servers.
Please post here the output of the following command, all in one line, to have an idea what is the situation: cat /etc/config/network; cat /etc/config/firewall; cat /etc/config/wireless ; cat /etc/config/dhcp ; ip -4 addr ; ip -4 ro ; ip -4 ru
These are wrong. You have the default gateway from the PPPoE (which by the way is 0.0.0.0/0.0.0.0) and the other two are unnecessary as you have the interfaces directly connected.
In Firewall zone LAN remove: masq and mtu_fix. Are you sure you need conntrack?
In firewall zone WAN add masq and mtu_fix and exclude the public addresses of the DMZ from NAT. Also you better change INPUT and FORWARD to DROP/REJECT.
SNAT for LAN to DMZ is pointless. Native routing works fine here and you have forwarding enabled. You only need to allow forwarding from WAN to the IP/ports of the servers in DMZ.
I do not really understand the firewall configuration at all - probably obvious.
I used LuCI to set this up. (I am quite happy using command line).
I don't really get what INPUT, FORWARD and OUTPUT actually do on a device like this. I don't know
what conntrack does either. How do I exclude the DMZ addresses from the forwarding?
Another thing that may be an issue is that I have my own nameservers for the LAN - one to cache
the public internet, and another to serve my internal hosts (there are about 40 IPs, some with more than six domains on). I would like the DHCP to give their IPs out with leases. I would also like to give the
routers IP (.254) out as a DNS server, and have the router query .100 (the caching server) rather than
use a hosts file.
The Nett business is that I am planning a subnet 192.168.1.0/24 at the end of a wire in one of the switch
ports. However, I need to get the basics working before I try to get clever! I realise the sensible thing
would be to have a 192.168.2.0 address on the router at the other end of the wire, but it is BT HH3,
not yet running OpenWRT, and very inflexible indeed. I have deleted it for now.
INPUT and OUTPUT is the policy applied to the interfaces bound to the zone. Generally OUTPUT can be ACCEPT for every zone. INPUT should be ACCEPT for zones that you trust, e.g LAN, but DROP/REJECT for untrusted zones, like WAN, GUEST, IoT. If the policy is DROP, then packets are discarded silently. Else with REJECT the router sends and ICMP message to inform of the discard (better for troubleshooting).
FORWARDING is for traffic traversing different interfaces of the same zone through the firewall. You only have one interface per zone, so not applicable in your case.
When you have DROP/REJECT policy, you need to manually open any ports or flows.
Forces connection tracking when NAT is disabled, in order to have stateful firewall. You could use it on the WAN interface for DMZ. Definitely not on LAN zone.
Basically you can exclude them by not including them in the addresses that will be NATed.
Add list masq_src '192.168.2.0/24' under WAN zone in firewall (or Advanced Settings tab of the WAN edit zone in Luci)
Thanks for your help, but I am in trouble - my WAN will not connect. I spent about 2 hours on the phone to BT getting the correct settings (I have VDSL FTTC). I cannot get it to connect. I have a HH5B unflashed, obviously, and that connects fine (but is no use cos the configuration options are too limited).
I have a second HH5A, which I also flashed with 18.06.2, and it also does not connect to the VDSL.
I tried to to a "sysupgrade" restore to 17.04, and it says the file is not a compatible format.
(Also, I tried to restore settings I saved, and it saves a tar.gz file, but restore wants gzip!)
Today everything is back to working fine on one of my HH5As with 18.06.2.
I suspect BT of fowl play, but after another "no fault found" call last night, its staying up.
The lessons learned are:
you can't trust LuCI to configure the firewall - you need to know how to do it (or know someone who does) and do it yourself.
BT VDSL is G993.2 and Annex B where I am (East London), However, it is annex A in some parts of the country. The VPI and VCI are 0 and 35 (not 38 or 32).
You can, but still you need to have an idea what you want to accomplish. Defaults will work fine and securely for the majority of the users. Therefore, each time you change some default setting you have to clearly understand why you would want to do that.