Project

General

Profile

Actions
Copy link

Bug #13226

open

Disconnecting a user from Captive Portal may allow previously established connections to continue.

Added by Danilo Zrenjanin 10 months ago. Updated 3 months ago.

Status:
Confirmed
Priority:
Normal
Assignee:
Reid Linnemann
Category:
Captive Portal
Target version:
CE-Next
Start date:
Due date:
% Done:

0%

Estimated time:
Plus Target Version:
Plus-Next
Release Notes:
Default
Affected Version:
2.4.5-p1
Affected Architecture:

Description

Steps to reproduce:

1. Connect to the network through the CP portal.
2. Establish OpenVPN forcing all traffic through it.
3. Under Status/Captive Portal disconnect your client.
4. Test the connectivity. Your Internet access still works.

Tested on the:

2.7.0-DEVELOPMENT (amd64)
built on Fri May 27 06:19:08 UTC 2022
FreeBSD 12.3-STABLE

Related issues

Related to Bug #11556: Kill all states associated with a NAT addressNewReid Linnemann02/26/2021

Actions
Actions
Copy link
 #1

Updated by Viktor Gurov 10 months ago

It looks like pfSense_kill_states() and pfSense_kill_srcstates() does not work properly:
https://github.com/pfsense/pfsense/blob/master/src/etc/inc/captiveportal.inc#L886-L888

Needs more testing.

Actions
Copy link
 #2

Updated by Viktor Gurov 10 months ago

  • Status changed from New to Confirmed

Able to reproduce.

It looks like pfSense_kill_status() and pfSense_kill_src states() are successfully kill TCP and ICMP sessions, but not UDP.

This may also be an issue prior to pfSense 22.05/2.7 (ipfw captive portal).

Actions
Copy link
 #3

Updated by Viktor Gurov 10 months ago

  • Assignee set to Reid Linnemann
Actions
Copy link
 #4

Updated by Marcos M 3 months ago

  • Subject changed from Captive Portal doesn't disconnect established OpenVPN link to Disconnecting a user from Captive Portal may allow previously established connections to continue.
  • Affected Version changed from 2.7.x to 2.4.5-p1

The root issue here is actually #11556. When pfSense_kill_states() is called, the state on WAN using NAT will remain due to the referenced issue, hence allowing reply traffic. That reply traffic will then reach the host behind the Captive Portal due the default rule which allows all traffic from the firewall itself. See the following states:

Before calling pfSense_kill_states()

all udp 198.51.100.7:1196 <- 10.0.1.100:62722       MULTIPLE:MULTIPLE
   age 00:01:05, expires in 00:01:00, 254:238 pkts, 42969:117085 bytes, rule 539
   id: db5e9a6300000000 creatorid: 4da82510 gateway: 0.0.0.0
   origif: vmx0
all udp 192.0.2.5:39681 (10.0.1.100:62722) -> 198.51.100.7:1196       MULTIPLE:MULTIPLE
   age 00:01:05, expires in 00:01:00, 254:238 pkts, 42969:117085 bytes, rule 145
   id: dc5e9a6300000000 creatorid: 4da82510 gateway: 177.231.47.1
   origif: vmx0.99

After calling pfSense_kill_states() and before reply from remote:

all udp 192.0.2.5:39681 (10.0.1.100:62722) -> 198.51.100.7:1196       MULTIPLE:MULTIPLE
   age 00:01:21, expires in 00:00:49, 264:248 pkts, 44119:118305 bytes, rule 145
   id: dc5e9a6300000000 creatorid: 4da82510 gateway: 177.231.47.1
   origif: vmx0.99

After calling pfSense_kill_states() and after reply from remote:

all udp 192.0.2.5:39681 (10.0.1.100:62722) -> 198.51.100.7:1196       MULTIPLE:MULTIPLE
   age 00:01:29, expires in 00:00:59, 268:253 pkts, 44569:118869 bytes, rule 145
   id: dc5e9a6300000000 creatorid: 4da82510 gateway: 177.231.47.1
   origif: vmx0.99
all udp 198.51.100.7:1196 -> 10.0.1.100:62722       MULTIPLE:MULTIPLE
   age 00:00:08, expires in 00:00:59, 5:4 pkts, 564:450 bytes, rule 143
   id: 65659a6300000000 creatorid: 4da82510 gateway: 0.0.0.0
   origif: vmx0

Actions
Copy link
 #5

Updated by Marcos M 3 months ago

  • Related to Bug #11556: Kill all states associated with a NAT address added
Actions
Copy link

Also available in: Atom PDF