Inbound firewall rule(s) not working

I have a Balance One with firmware 7.1.2 and one WAN interface enabled. WAN1 interface is in NAT / DHCP mode. No NAT mappings defined.

There’s one port forwarding rule enabled on the WAN1 interface to an internal NAS (LAN address).

With default inbound firewall rule of “allow all” everything works (as expected).

If I add a deny inbound firewall rule above the default rule like this:

protocol: TCP
source IP: any
source port: any
destination IP: internal LAN IP of the NAS
destination port: NAS port

I get a lot of deny logs in the event log, but I can still connect from the Internet to my NAS!

CONN=WAN1 MAC=XXXXX SRC=213.233.108.169 DST=10.X.X.X LEN=64 TOS=0x00 PREC=0x40 TTL=53 ID=0 DF PROTO=TCP SPT=19486 DPT=5001 WINDOW=65535 RES=0x00 SYN URGP=0 MARK=0xd

I even changed the default inbound rule from allow all to deny all and I can still connect!

This is the port forwarding configuration:

This is the firewall configuration:

Why is this behaving like this? Wasn’t the firewall supposed to block the external access if deny all is configured?

Thank you all for support!
Mihnea

Hello @mmc70,
In reading though this we read it as you wanting to only allow port # 5001 to your internal server from the outside on WAN1.
If so, just remove the inbound firewall rule “Block remote NAS acc…” as your port forwarding rule will be enough.
Happy to Help,
Marcus :slight_smile:

Hi Marcus,

Thanks a lot for replying!

My port forwarding works, I have access, that’s not the issue.

What I want to do is to allow external access to my internal NAS only during certain hours. That’s why I created a schedule for this firewall rule. And the external access still works in spite of my rule(s)!

Anyway, the questions stands: why does the Balance ignore the DENY rules for inbound? This is scary.

Thanks again,
Mihnea

As you have written it, the deny rule only blocks port 5001. Many NAS use multiple ports. To test the theory simply change the default rule to Deny ALL. Personally thats the first thing I do with my routers, I don’t agree with the default but I understand its reasons.

Another way to test is to go to the Sessions table and search for your NAS IP. You’ll see all inbound and outbound sessions including the port in use.

For your goal I would have default = deny all, with a rule before that allows the desired access only.

1 Like

Hi Don,

The default rule is DENY all. It’s in the picture I posted (the red icon).

The NAS uses only 1 port for access, the HTTPS 5001.

The trouble is that I can see the denied connections in the log, but access is still allowed on that particular port! That’s the strange thing.

1 Like

OK. I haven’t got chance to test this theory yet but I think what you’ve confirmed is that the process of opening a port when in NAT mode overrides the firewall. The logic here is admin has opened port therefore admin wants inbound traffic on that port and if admin sets deny all then admin really means deny all (apart form ports I have opened) so implement that.

Instead of deny all on inbound to port 5001 get more specific. Deny the IP that you are testing remote access from. Does a specific rule targeted as a specific source IP block inbound traffic from that source IP?

As an aside I always block services with outbound rules and that always works as you’d expect.

2 Likes

Could it also be that the router is doing double NAT and firewall rules cannot be inserted/enforced there? Not an expert, so this is a simple hunch :blush:

Thank you for the suggestion of blocking outbound rules, I will try to do that and see how it goes. Basically I will be allowing connections to the internal server, but block the answers.

I will let you know how it goes.

Thanks!

So, I added a DENY Outbound Firewall Rule like this:

protocol: TCP
source IP: internal LAN IP of the NAS
source port: any
destination IP: any
destination port: 443

and there’s the same behaviour: the firewall logs a deny event, however the connection still works in spite of the deny!

CONN=vlan MAC=XXXXX SRC=10.X.X.X DST=138.68.36.199 LEN=60 TOS=0x00 PREC=0x00 TTL=63 ID=11525 DF PROTO=TCP SPT=58948 DPT=443 WINDOW=14600 RES=0x00 SYN URGP=0 MARK=0x3

It’s the same, the rule does not get enforced somehow, although it’s clearly evaluated.

The external access works on HTTPS only, so the rule is correct.

Hello @mmc70,
We recommend that you raise a support ticket here for this
https://contact.peplink.com/secure/create-support-ticket.html
(as found on the Peplink Contact Us page)

You will need to grab your devices Diagnostic Report file from the Status page of your router to attach to your support ticket, a guide to finding this can be found in this article.

Post your support ticket # back here in the forum once you have received the ticket number.
Happy to Help,
Marcus :slight_smile:

1 Like

Thank you, Marcus!

Just opened ticket #791197. I linked this support thread in the ticket for details. since it’s pretty detailed.

Mihnea

1 Like

Martin, I tested that in response to your message. I have several servers behind my Balance, all of which have port forwarding. I changed the first firewall rule to Deny All. I immediately lost external access to those servers. Removed the firewall rule, and everything works again. Apparently the port forwarding does not override the firewall rule.

Getting back the original question, mmc70’s firewall rule as written blocks inbound access through port 5001 to a particular address (its blacked out in the image). The blacked out area doesn’t seem to be large enough for an IP. What is behind there, the device name? I would change the blocked destination to ANY device using port 5001 and see what happens.

2 Likes

The blacked out IP is from the internal class 10.0.x.x, that’s why it looks so short. I can assure you it’s a legitimate IP, the traffic reaches it very well – to well actually (in spite of all deny rules), that’s the issue!

Let’s see if Support can pinpoint the issue. I left the router with Remote support enabled, they may do whatever changes they consider fit to solve this.

1 Like

@mmc70

Would you able to share us on how you access your NAS server via internet ?

2 Likes

Sure thing. I am using Synology’s iPhone apps for that: DS File and DS Cam.

Interestingly though that external browser access to port 5001 does not work anymore. I only checked with the above apps, which seem to use port 5001 over https as well according to Synology:

I could post exact IPs and links on the support ticket, the forum is not secure. Please let me know how you wish to proceed.

Thank you.

@mmc70

Yes please. Please post the access link via the ticket and support team will follow up with you via ticket.

For sure the firewall rules is working and just the matter of need to understand the application traffics direction especially some application may connect via cloud and we need to create back the related firewall rule to block the traffics.

2 Likes

That explains it. I use Synology servers. I am connected from my home to work on my smartphone right now, using DS File, through a cellular connection.

I logged into the Balance at work to see what inbound sessions are going to the Synology server. There are no inbound connections, but yet I am browsing the files on my phone. How?

The answer is that the Synology server maintains its own outbound connection to synology.com via port 443. When you use the DS File app via myservername.quickconnect.to or myserver.synology.me, your remote device is connecting to Synology’s server, not your local device. Your local device is initiates and maintains its own connection to Synology to complete the loop.

There is no inbound connection to block. To test on your end, go to Status > Active Sessions on your Balance. Click search and enter the LAN address of your Synology box. You’ll see the outbound connection.

If you still need to block users certain times of the day, you would block the outbound connection to the Synology IP shown on the session list. Mine is showing 216.176.185.212.

4 Likes

Hi Don,

Thank you for taking you time to do into this issue.

Unfortunately I don’t have QuickConnect enabled on the NAS. Synology explains how that works in a very detailed document. I also don’t have UPnP enabled on the router and I also have a DENY outbound firewall rule exactly to prevent the NAS initiating HTTPS connections outside.

You can see the logs in the thread above. The rules get triggered, however the traffic for DS File still works.

You were right in that the router does not show any inbound active connections while the DS Files IOS client is connected.

The strange part continues to be that the DENY rules, either inbound or outbound, get triggered and log the deny events, and the connection still gets through!

I will try to save some screen captures today and post them in the support ticket for the Peplink team to see.

I have blocked on the router both TCP and UDP ports from NAS to external 443 and connection stopped! Don, you were right on the money!

After that I have played with Synology NAS settings in the Quick Connect area and, even if the feature was disabled, it seems it somehow kept connections to Synology external servers. I have re-enabled it just to get access to the Advanced configuration tab, where there were several other settings checked. I unchecked Enable QuickConnect relay service and then disabled the QuickConnect feature again (to allow the NAS to re-register the new settings with Synology’s cloud) and bingo! external access through mobile apps stopped.

Conclusion: Synology’s QuickConnect feature keeps live connections to external Synology cloud using both TCP and UDP tunnels to port 443. If we block only TCP, connections succeed over UDP.

Unfortunately if we block all connections from the NAS to 443 everything gets messed up on the NAS: no DDNS (Synology ddns server), no e-mail notifications, which all seem to work over SSL tunnel.

Therefore the router/firewall works correctly, however my goal of allowing remote access to the NAS using the mobile apps (DS file) only during the weekdays could not be configured. Well, that’s life :slight_smile:

Thank you all again for your support! Great community here.