Change the default rule like this so it actually drops traffic that is not let in explicitly:
Example of how your RDP rule should look:
1 Like
Friend … it seems you do not want to understand what I’m presenting here.
I did exactly what you ask of me, and I explain again, what you marked in the blue box, as soon as I move to DENY everything is blocked. And no matter what you set in RULL.
Anyway, after such a loophole, I move all my sites to checkpoint and Fortigate, and not true to what I found out and too bad I admired Peplink.
I give up. Anyone else want to try? 
Your screenshots show the source ports the same as the destination.
I explained to you in very basic terms why that does not normally need to be the case and why it likely means that when you set the default rule to DENY “everything is blocked” because ITS NOT BEING MATCHED BY THE RULES ABOVE IT CORRECTLY.
Post a packet capture then if you’re so sure that is wrong, or do like I said and enable logging on the rules to see if they are even being hit… or how about you open a support ticket as I’m sure Peplink would love to hear about this “loophole”.
Spoiler alert though, it is not a “loophole” just an end user who cannot properly configure a firewall - good luck Fortigate (and Checkpoint), I can promise you that if you configure like for like rules on those boxes it will also not work as both Forti and CP at least both drop inbound by default and your rules are fundamentally flawed.
1 Like
There is no loophole.
When the default rule is set to deny you say everything is blocked - this is expected. When set to deny we have to build each and every desired allow access rule individually. We layer on top of the deny all / all.
It is very rare to need to deny all / all. The Peplink firewall is stateful and the only ports that get opened inbound (automatically) on a WAN with NAT enabled are those configured in port forwarding and those needed for enabled services (eg SpeedFusion VPN). All other inbound traffic is blocked by the stateful firewall by design.
If you have WANs that use IP forwarding rather than NAT (ie WANs connected to other parts of your internal network for internal routing) then all inbound traffic is allowed unless you specifically block it.
But the bigger question is what are you trying to do with the firewall?
It looks like you are creating rules for inbound access to internal services, but each of the rules is set to allow and each rule is configured to identify the source traffic by a source port that is very unlikely to be used by a source device anyways.
You are in effect allowing all inbound traffic on the ports you have already opened (default allow allow combined with port forwarding configuration), then adding additional rules to again allow inbound traffic from all remote IPs so long as they are using specific source ports for their traffic (source ports that are very very unlikely to ever be used by the remote devices).
Tell us what you are trying to achieve and we can help you build a ruleset to accomplish it.
In your original post it looks like you are trying to log inbound connections? In which case set the source ports to any and then you’ll see the traffic logged. eg: the following will log RDP inbound to 172.16.10.251
4 Likes
I’ll have a go (though the answer has been provided in multiple ways already)
It does not. It allows access to NVR from any address on port 8200 as long as the originating port is also 8200.
This is unlikely ever to be triggered (cfr. the explanation of how originating ports are used in standard networking, and further modified if originating NAT is involved).
It does not. It allows access to NVR from any address on port 8100 as long as the originating port is also 8100.
This is unlikely ever to be triggered (cfr. the explanation of how originating ports are used in standard networking, and further modified if originating NAT is involved).
It does not. It allows access to NVR from any address on port 55401 as long as the originating port is also 5540.
This is unlikely ever to be triggered (cfr. the explanation of how originating ports are used in standard networking, and further modified if originating NAT is involved).
It does not. It allows access to NVR from any address on port 55751 as long as the originating port is also 55751.
This is unlikely ever to be triggered (cfr. the explanation of how originating ports are used in standard networking, and further modified if originating NAT is involved).
It does not. It allows access to NVR from any address on port 3389 as long as the originating port is also 3389.
This is unlikely ever to be triggered (cfr. the explanation of how originating ports are used in standard networking, and further modified if originating NAT is involved).
These rules are never triggered, so the firewall proceeds to the final any to any rule, allowing all connections to succeed in passing the firewall. And if your final rule is turned into a “deny” rule then all the incoming traffic will be denied.
As the previous posters have explained, for all the rules replace the originating port designation with “any” and then make the final (default rule) a “deny” rule.
To see that this all works as expected, turn on logging for each rule, and the log will tell you which rule is triggered.
Cheers,
Z
3 Likes