Smart Router port forwarding in DMZ randomly stops working

[c2r]

Hello,

I've recently been upgraded to FTTP with the white Smart Router, and all the discs to provide wifi around the house.  The discs are brilliant, and I'm generally really happy with the router - however, every day or so, it just decides that it doesn't fancy doing port forwarding anymore.

I'm running Smart Router DX

Software version is: v0.04.01.05202-EE

Board version: R01

Boot loader; 0.1.7-EE (20.09.2019)

Firewall is on

I've got a device called "dmz.local" which is detected and has private IP 192.168.1.208

I've set this device to be the DMZ device and have a rule for sftp to forward a high numbered port, say 19888 to 22 for TCP and UDP

I'm also forwarding port 80 to this device.

ShieldsUp reports no vulnerabilities on common ports.

The device, dmz, has its own firewall, which I've disabled for testing purposes.  The device is at all times able to be accessed from the local network, and is able to be accessed via the public facing IP address initially.  However, after, perhaps a day or so of use, it stops being able to be accessed from the externally facing IP address, the connection just times out with nothing in the ssh logs on the device itself.  It can still be accessed from the internal network.

The internet itself is still up, as outgoing connections/requests work, and the device is still up and working (as above, it can be accessed directly on the local network).

Following a reboot of the router it's again immediately available.  I travel for work and need a reliable connection back to my home network so rebooting the router every day isn't an option. 

Port forwarding worked fine with the old brightbox router and I didn't have this problem - but I don't want to go back to using the old router as the new one has all the wifi discs which now I need for wifi calling without the landline.

Has anyone got any suggestions on anything I can try to fix this issue?

Thanks

Chris

[c2r]

Hello,

Thanks, yes, the pi emails me my external IP address every time it changes, also it updates a dynamic dns provider.  My external facing IP address hasn't changed for some time.

Attempting to reconnect (either by ip address or external name) does not re-establish the connection, unless the router is restarted, after which it works immediately.

It's not therefore possible to reestablish the connection remotely, which means if I'm not at home I need to get someone else in the house to restart the router (from the router's admin screen), after which it can be accessed remotely again.

Cheers

Chris

[mikeliuk]

It does sound a lot like a service or daemon in the router is falling over and or for some other reason the port-forward functionality is simply stopping.

One step to debug may be monitor two simultaneous port-forwards perhaps one on a low numbered port below 1000, and one on a high numbered port (e.g. five digits), and check if they drop at the same time and no longer forward packets (connections don't re-establish if manually forced). The next step may be to consider disabling IPv6 (speculative) or swapping out the router to debug with another router.

[c2r]

Cheers,  it's annoying that there's no better logging that I can see on the router to determine what's going on...

* it did used to work on the old brightbox2 router; the issue has only started since moving to the white smart router - which otherwise is brilliant with all its discs for mesh wifi.

* when it goes down, if I try and connect from a third location (e.g. tethered SIM card or work VPN) then it is inaccessible - almost like the firewall gets overloaded or something and then opts not to play anymore at all.

* I've opened a second low numbered port to see if that also stops working next time it goes down.  As above, I'm running a high numbered port to serve ssh/sftp

* Router IPv6 status= enabled currently, network status=disabled; ipv6 wan details=not available; ipv6 lan details=not available; ULA disabled, allocation mode=off, no pinholes

Cheers

Chris

[mikeliuk]

Typically I do not recommend making more than one change before observing the impact when debugging but in this case I don't think that opening an additional port counts as a change.

I also generally do not recommend disabling IPv6 support but in the case of this service provider, which shall not be named, there is anecdotal evidence that disabling of IPv6 support can result in better stability. My hypothesis is that enabling IPv6 functionality may cause attempts to obtain a valid configuration by DHCPv6 but if the network does not have IPv6 functionality enabled this may always fail and eventually cause an error condition and various restarts leading to loss of functionality such as port-forwards.

As you see that no IPv6 configuration is received anyway, I would suggest to disable IPv6 functionality to see if this results in any improvement of port-forwarding behaviour. I would also suggest that you record the interval between occurrences of the port-forwarding issue as it may happen at a regular time interval which would be indication of some sort of timeout or limit being hit. It's possible disabling IPv6 functionality could result in better stability of the port-forward so you would just need to make a note in case the service provider ever enables IPv6 functionality on their network so you would want to re-enable to match to be future-proofed.

It's possible you would only need to disable and re-enable the port-forwarding functionality to bring it back up (potentially this may imply a router reboot as the last step, but possibly the change can be made without reboot which would be more informative) and this is also indicative of discrete services causing the problem and not a wider network or router issue.

[XRaySpeX]

@mikeliuk : The anecdotes you read about IPv6 are regarding the mobile network only. There is no IPv6 on the fixed BB network.

[mikeliuk]

It is *because* there is no IPv6 functionality on the fixed line network that I suggest to disable the functionality in the router.

Edit: worst case it will be a completely harmless change.

Edit2: the purpose of the proposed change is to rule out my hypothesis. The scientific method is to propose a hypothesis and then attempt to falsify it, which will be done if IPv6 is disabled in the router but port-forwarding functionality still drops.

Edit3: browsing the related discussions at the bottom of this thread, I see that port-forwarding should just work (most issues being the firewall on the target) although there is one example of a suspected faulty router https://community.ee.co.uk/t5/Broadband-home-phone/New-EE-Smart-Hub-amp-Port-Forwarding-or-lack-of/m...

Edit4: I'm completely open to debugging an alternative hypothesis that might explain the issue and symptoms observed. It's possible the intervention might also be more simple than unchecking a tick box.

[XRaySpeX]

Edit3: It's pointless & nowt to do with the issue.

I've never seen so many red herrings as in your posts. You'd be better off heeding Occam's Razor.

[c2r]

Hello,

I'm still getting this issue - some further information;

* the low numbered port is also inaccessible so it isn't just the high numbered port that it has opted close

The log when this occurs is pretty much immediately full and truncated, so it's never possible to get back to the detail around the initial messages on the firewall log.

Has anyone got any other suggestions?

Cheers

Chris

[mikeliuk]

Hi @c2r ,

As you await an expert opinion, I thought I would mention that your original idea of putting a secured host in the DMZ is a good one.

You could remove all port-forwards from your router, ensure your DMZ host is properly firewalled with firewalld, or a similar software firewall, and open the ports you require directly on the host.

Any incoming, unsolicited traffic which hits your WAN interface would then be forwarded on to your DMZ host. If you find that even this functionality fails (i.e. DMZ functionality fails), it would then be time to consider a new router.