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

[XRaySpeX]

Just some odd Qs:

1. ---

   @c2r wrote:
   

   ShieldsUp reports no vulnerabilities on common ports.

   ---

    Not even on port 80 which you've opened?

2. What does ShieldsUp! report on your custom port 19888?
3. Why does this device need to be in the DMZ?

[c2r]

Thanks for the quick reply. 

Sorry, I should have been more clear, 80 and 19888 report as open, because I've opened them, similarly ShieldsUp also reports that it's able to ping my public facing IP. 

But other than that there's no vulnerabilities listed.

19888 specifically states: Unknown Protocol for this port  Unknown Application for this port

The device doesn't need to be in the DMZ for any particular reason - I just put it there because I thought that the router's firewall could be causing the issue (the issue occurred before I moved the device to the DMZ), and for obvious reasons I didn't want to disable the router's firewall.

Thanks again

Chris

[mikeliuk]

Apologies if I'm being an idiot but I thought a host in the DMZ is supposed to by-pass the router firewall and that all traffic reaching the router's IPv4 IP address which is not NATed traffic for another host (an established connection) should be forwarded to the DMZ host.

It sounds like there's a chance that the router is behaving as configured and established connections are forwarded by NAT and new connections go to the DMZ host.

To test, one can disable the DMZ to see the port-forward works as expected. The DMZ can be reenabled to see new connections arrive to the DMZ host. The port-forward can then be removed to see all externally-initiated traffic hits the DMZ host. 🤓

[c2r]

ah, ok, I hadn't realised that was how the router was treating the DMZ.

I'll try disabling the port forwarding and seeing what happens and will report back.

Thanks for your help

Chris

[mikeliuk]

A quick aside for anyone else that comes across this thread that obviously all debugging of port-forwarding and DMZ needs to be done from a host external to your network which accesses the internet using a different IP address from your router.

For example, you can tether or hotspot to a second SIM in a mobile phone to give you your external host.

Once things work from an external host, careful configuration can often get everything working transparently inside the network too. For example, by ensuring external hostnames resolve to internal IP addresses instead etc.

[XRaySpeX]

@mikeliuk : All you need for testing of open ports is an external site, like ShieldsUP!, which you can reach from your BB network, just like OP did.

[mikeliuk]

Completely agree. In my case, I was configuring an OpenWRT VPN https://openwrt.org/docs/guide-user/services/vpn/start so indeed used an external service to check my ports were open, but needed to put my laptop onto another network to check the configuration actually worked.

Obviously I'm not going to provide my credentials to an external service to check they can access my VPN. That would defeat the purpose of setting up the VPN! 😂

Edit: the thing was I was trying to head off is that many times an engineer will test a particular service (not just whether a port is open) to see it works inside their network and be surprised that another user cannot get something to work because they are testing from outside the network.

Edit2: there are also services such as wireguard that cannot be detected as an open port so only a test of functionality will verify it works. 🤓

[c2r]

Hello,  I've brought the device back out of the DMZ and have the port forwarding set up as before - however, remote connections have failed again this morning - the router log gives me the follow, repeating several times:

24 May. DoS(Port Scanning): IN=ppp0 OUT=br0 MAC= src=<REMOTE IP> DST=192.168.1.208 LEN=52 TOS=0x00 PREC=0x00 TTL=114 ID=43399 DF PROTO=TCP SPT=59005 DPT=23 WINDOW=65535 RES=0x00 SYN URGP=0 MARK=0x8000000

However, all I'm trying to do is connect remotely using the SRC IP address using sftp public/private key authentication (I've checked that it isn't a genuine DoS attack) .

The device itself is still accessible via ssh from other devices on the internal network, it's only if I try and get in from outside that it just appears to have blocked access.

Does anyone have any ideas about what's going on here as it's really quite frustrating!

Thanks in advance

Chris

[mikeliuk]

I'm assuming your router receives a publicly routable IPv4 address so that it can be reached from outside at all.

Have you already accounted for the fact your public-facing IPv4 address could change or have you verified that it has not changed?

Does a simple re-run of the remote command re-establish the connection? On your remote side, are you able to add options so that the command automatically sends heart-beat packets to keep the connection open, and so that a connection drop is automatically detected and re-established as required?