Following the industry adopted convention, I assumed that peplink FW incoming rules are applied to the raw ingress packages that has NOT been modified yet in any way by peplink device. Moreover, the destination address/port entries refers to the WAN side of the peplink device. Apparently, I proven wrong…
Are the port-forwarding rules apply to the ingress packages first and then being evaluated by FW module? Thus, destination address and port belong to servers on the LAN side of the peplink device?
The firewall rules are evaluated and executed before any port forwarding rules, and for incoming rules the destination address and port would be to the servers on the LAN side.
From my experience, you are only partially correct, and here is why…
In my scenario, I allow SSH incoming traffic to port 2022 from predefined public IPs. Then packets get
forwarded to LAN server listening on port 22. So I’ve setup FW and Port Forwarding (PF) rules (see bell
ow). Intuitively, I entered port 2022 as destination for FW rule. It did not work, so I’ve changed to 2
2
and the packets start flowing. Thus…
1- When entering FW rules, one has to be conscious about port forwarding rules since FW looks at the pa
ckage before PF (for source IPs) and after PF (for destination IPs and ports). This does not make sense
to me, as you create unnecessary dependency between FW and PF rules. FW should treat destination IP/po
rts as ones that assigned to WAN side of the peplink 20 (vs LAN side)
2- Imagine that I have multiple SSH servers on my LAN. And I assigned various incoming ports (on peplin
k WAN side) to reach them 3022, 4022 and 5022. In addition, access to the SSH server is restricted by p
ublic source IP. So how would you design FW rules in this case? Since destination port for FW rule is i
dentical for for all SSH servers, you have to come up with another discriminating factor and it can NOT
be WAN side incoming ports?
The inbound firewall rules only applies to the following types of traffic:
Inbound traffic that is defined in Inbound Services
Inbound traffic that is defined in Inbound NAT Mappings
For example, if you define inbound service as Port Mapping 192.168.x.x (2022 -> 22), firewall will filter traffics based on Any -> 192.168.x.x (22). If you define inbound service as Single Port 192.168.x.x (2022), firewall will filter traffics based on Any -> 192.168.x.x (2022).
Below is our firewall and conventional firewall design:-
Ssh server 1 - 192.168.1.1 (22), 1.1.1.1 (3022)
Ssh server 2 - 192.168.1.2 (22), 1.1.1.1 (4022)
Ssh server 3 - 192.168.1.3 (22), 1.1.1.1 (5022)
