Confusing UI: Inbound Firewall Rule vs Local Services

[soylentgreen]

I think there’s a serious security issue here:

See related thread VPN hack attempts vs. Intrusion Detection and DoS Prevention

• My firewall has the following rule:
  

  

• The rule is being triggered properly and shows up in the Firewall Event Log:
  

  

• However, it appears that these connections (which are a VPN-password-guessing attack) are still being processed by the Peplink:

• Possibly Relevant:
  The target internal IP address (10.0.64.98) is set up using NAT Mapping to one of my static public IPs:

Based on this, I belive the bug report title is:

NAT Mapping allows inbound VPN access to bypass the Inbound Firewall Rule

This seems like a serious security problem, if true.

[soylentgreen]

Further detail - checking the firewall logs, I am unable to match up the timestamps between the VPN hack attempts and the firewall rules triggering. Notice the latest VPN hack attempts happened at 01:50:43 and 01:50:39 but the firewall rules are not triggered at the same time, instead triggering at 01:51:01 and 01:49:21.

This suggests that the firewall rule is blocking something, but it’s failing to block the VPN access requests.

[MartinLangmaid]

@soylentgreen

My firewall has the following rule:

You need to add that rule to ‘Local Service Firewall Rules’ not inbound firewall rules.

[soylentgreen]

Hmm. If so, that’s poor and confusing UI design for several reasons:

1. If Local Service Firewall rules apply First, then the UI for it should not be at the bottom of the firewall UI page. It should be located in front of (higher up) on the page than the Inbound Firewall Rules section.

2. The Help tag for Inbound Firewall Rules section needs to mention this. It currently reads:

This table displays all the configured inbound firewall rules and their details. Dragging a rule up/down can change its priority, higher position of a rule signifies higher precedence.

For every new inbound IP session routed to a host on the LAN (i.e. sessions coming from WAN side), rules will be matched from the top to bottom. The matching process stops when a rule is found to be matched.

The inbound firewall rules only apply to the following types of traffic:

• Inbound WAN 1 traffic where the WAN 1 is in drop-in mode
• Inbound traffic that is defined in Port Forwarding
• Inbound traffic that is defined in Inbound NAT Mappings

If an inbound IP session does not match any of the rules listed, the Default rule will be applied.

I would suggest adding the following to the help:

Note: Local Firewall Service Rules (such as VPN access…) rules are applied before these rules.

3. The name itself, Local Service Firewall Rules is somewhat misleading - when I read “Local Service” my mind certainly does not jump immediately to “Remote VPN access”. “Local Service” sounds more like Bonjour or similar…

[soylentgreen]

Martin, thanks for the solution - I ended up creating the rule in both sections (Inbound and Local) because I really want this Russian hacker blocked, and after creating the two rules, I can confirm this is working.

I’m changing the title of this post to reflect a better understanding.

[MartinLangmaid]

Glad you got them blocked.

Completely understand why you found this confusing - most people do, so yes I think its due a UI / UX rethink.

[soylentgreen]

I may have spoken too soon - it looks like the VPN hacker is only making attempts at night.

Here’s a snippet of the Device Event log from last night:

And here’s the Firewall Event log for that same time:

And here’s what my 2 firewall rules look like - I have one of these in Local Service and one in Inbound rules:

Am I doing something wrong here or is there perhaps a bug?

[MartinLangmaid]

Log a ticket for engineering review.

[soylentgreen]

Submitted as ticket # 20070801

[soylentgreen]

An update on the ticket: Peplink Engineering says that my observations are correct, and the internal service firewall rule is not working currently for PPTP VPN connections. Tthey recommend switching to OpenVPN as a mitigation at the present time.

[mystery]

Is it fixed in 8.1 final?

[TK_Liew]

@mystery, we will enhance the Local Service Firewall by adding more services in the future firmware release.