Bug #15633: Limiters applied to OpenVPN interface do not apply for download traffic - pfSense - pfSense bugtracker

Custom queries

2.4.5-p1 - Resolved/Closed
2.5.0 - Resolved/Closed
2.5.1 - Resolved/Closed
2.5.2 - Resolved/Closed
2.6.0 - Resolved/Closed
2.7.0 - Resolved/Closed
2.7.1 - All Open Issues
2.7.1 - Resolved/Closed
2.7.2 - Resolved/Closed
2.8.0 - All Open Bugs
2.8.0 - All Open Features
2.8.0 - All Open Issues
2.8.0 - All Open Regressions
2.8.0 - Feedback
2.8.0 - Needs Attention
2.8.0 - New/Confirmed
2.8.0 - Pull Requests
2.8.0 - Regressions affecting 2.7.0
2.8.0 - Resolved/Closed
21.02.2/2.5.1 - Resolved/Closed
21.05 Plus - All Closed Issues
21.05.1 Plus Target - All Closed Issues
21.05.1 Target - All Closed Issues
22.01 Plus - All Closed Issues
22.01 Target - All Closed Issues
22.05 Plus - All Closed Issues
22.05 Target - All Closed Issues
23.01 Plus - All Closed Issues
23.01 Target - All Closed Issues
23.05 Plus - All Closed Issues
23.05 Target - All Closed Issues
23.05.1 Plus - All Closed Issues
23.05.1 Target - All Closed Issues
23.09 Plus - All Closed Issues
23.09 Target - All Closed Issues
23.09.1 Plus - All Closed Issues
23.09.1 Target - All Closed Issues
24.03 Plus - All Closed Issues
24.03 Target - All Closed Issues
24.11 Plus - All Closed Issues
24.11 Plus - All Open Issues
24.11 Plus - Feedback Issues
24.11 Plus - Needs Attention/Work
24.11 Plus - New/Confirmed/In Progress Issues
24.11 Target - All Closed Issues
24.11 Target - All Open Issues
25.01 Plus - All Closed Issues
25.01 Plus - All Open Issues
25.01 Plus - Feedback Issues
25.01 Plus - Needs Attention/Work
25.01 Plus - New/Confirmed/In Progress Issues
25.01 Plus - Pull Request Review
25.01 Plus - Waiting on Merge
25.01 Target - All Closed Issues
25.01 Target - All Open Issues
All Open Issues assigned to Me
All Open Pull Requests
Any Target - All Open Regressions
Any Target - Feedback Issues
CE-Next - All Closed Issues (Move to specific target)
CE-Next - All Open Issues
CE-Next - Feedback (Likely needs target changed)
New Issues by Category - Future Target
New Issues by Category - No Target
New Issues by Category - No Target+Future
No Target - All Open Issues (Base Only)
No Target - New Issues (Base Only)
No Target - New Issues (Base and Packages)
Release Notes - Plus Target Version (DO NOT EDIT)
Release Notes - Target Version (DO NOT EDIT)

Actions

Copy link

Bug #15633

closed

Limiters applied to OpenVPN interface do not apply for download traffic

Added by Phil Wardt 4 months ago. Updated about 2 months ago.

Status:

Resolved

Priority:

Normal

Assignee:

Category:

Traffic Shaper (Limiters)

Target version:

Start date:

Due date:

% Done:

Estimated time:

Plus Target Version:

Release Notes:

Default

Affected Version:

Affected Architecture:

amd64

Description

There is an issue appeared after recent pfsense updates (which ?)
Limiters applied to shape traffic on OpenVPN (configured as server) interface apply only for client uploads.
Previously the limiters were properly applied to both download and upload traffic (in/out on the interface)

The only way to apply the download limiter is now on WAN interface.
However, you cannot limit specific OpenVPN clients by their IP from there !
The only solution I found and that it still works is to Tag the rule on OpenVPN interface and shape it on the floating tab using "Match" and the tagged string

Is this by design or it is a bug in current pfsense release ?

Files

Firewall rule on assigned OpenVPN with WAN gateway specified.png (103 KB) Firewall rule on assigned OpenVPN with WAN gateway specified.png

Azamat Khakimyanov, 10/05/2024 05:09 PM

History
Notes
Property changes

Actions

Copy link

Updated by dylan mendez 4 months ago

Unable to replicate this on pfSense Plus 23.08 devel.

Setup: OpenVPN Server with a firewall rule with Limiters In/Out of 5Mbps.

In Limiter is setup with Source Address as Mask.
Out Liumiter is setup with Destination Address as Mask.

5Up/5Down client limited without issues.

Also tested on 2.7.2 with the same result, unable to replicate.

Actions

Copy link

Updated by Phil Wardt 4 months ago

dylan mendez wrote in #note-1:

Unable to replicate this on pfSense Plus 23.08 devel.

Setup: OpenVPN Server with a firewall rule with Limiters In/Out of 5Mbps.

In Limiter is setup with Source Address as Mask.
Out Liumiter is setup with Destination Address as Mask.

5Up/5Down client limited without issues.

Also tested on 2.7.2 with the same result, unable to replicate.

Ok, I further tested :
I started again with new limiters, set like you noted
If applied on the common OpenVPN interface, the limiters work in fact. Also my old set limiters with the queue

However, if applied to the interface of only that OpenVPN server, only the upload limiter works. The download (out) is not applied
I am sure it was properly working on version 2.6.x when I set it up first and never verified it until I noticed some abuse a few weeks ago

Since the global OpenVPN interface rules are processed first, this is not a workaround for me as I'd need to setup all my rules on this same interface instead of segmenting them on the different OpenVPN servers interfaces

Actions

Copy link

Updated by Azamat Khakimyanov 2 months ago

Status changed from New to Resolved

Tested on 24.03 and on 24.08-DEVELOPMENT (built on Fri Sep 13 17:46:00 UTC 2024)

IN and OUT Limiters work correctly when they are applied on common (global) OpenVPN interface but they don't work at all if they are applied on assigned OpenVPN interface.
But if to use Floating firewall rule with 'Quick' checked and 'Direction: IN', Limiters might be applied on assigned OpenVPN interface also.
So segmenting Limiters on the different OpenVPN servers interfaces might be done by using Floating firewall rules.
And Limiters which are applied on common (global) OpenVPN interface take precedence over the Limiters which are applied on assigned OpenVPN interface.

I marked this Bug as resolved.

Actions

Copy link

Updated by Phil Wardt 2 months ago

Azamat Khakimyanov
Why close the bug report when you recon that limiters don't work at all on assigned vpn interfaces? And your assumption is wrong. On assigned interface, the upload limiter does work!
I didn't read anywhere that's how it is by design. Furthermore, it was working properly in previous versions.

Actions

Copy link

Updated by Azamat Khakimyanov about 2 months ago

File Firewall rule on assigned OpenVPN with WAN gateway specified.png Firewall rule on assigned OpenVPN with WAN gateway specified.png added

Tested on 24.03

Some comments about OpenVPN + Limiters:
1. with 'Allow any any' firewall rule on the "OpenVPN" default interface, Limiters on the assigned OpenVPN interface don't work at all.

2. with any allowing firewall rule on the "OpenVPN" default interface with specified 'Source' and 'Destination' (but Destination is not ANY and without 'Allow any any' firewall rule), Limiters on the assigned OpenVPN interface work only in the uploading direction.

3. with any allowing firewall rule on the "OpenVPN" default interface with specified 'Source' and 'Destination' (but Destination is not ANY and without 'Allow any any' firewall rule) or with no rule at all AND there is allowing firewall rule on assigned OpenVPN interface with 'Disable reply-to' checked , Limiters on the assigned OpenVPN interface work in both directions.

And Limiters also work in both directions if default pfSense gateway (WAN gateway) is specified on allowing firewall rule on assigned OpenVPN interface (without 'Disable reply-to' checked) (see attached 'Firewall rule on assigned OpenVPN with WAN gateway specified.png').

So I would say it's not a Bug but it's how OpenVPN works and there are several methods to use Limiters to restrict traffic for OpenVPN:
- Limiters on assigned OpenVPN with 'reply-to' disabled or default gateway specified.
- Limiters + Floating rules with 'Quick' checked and Direction specified.

Actions

Copy link

Also available in: Atom PDF

Project

General

Profile

pfSense

Custom queries

Bug #15633

Limiters applied to OpenVPN interface do not apply for download traffic

Updated by dylan mendez 4 months ago

Updated by Phil Wardt 4 months ago

Updated by Azamat Khakimyanov 2 months ago

Updated by Phil Wardt 2 months ago

Updated by Azamat Khakimyanov about 2 months ago