Project

General

Profile

Actions
Copy link

Bug #1632

closed

Captive Portal changed behaviour

Added by Davide B almost 14 years ago. Updated over 9 years ago.

Status:
Rejected
Priority:
Normal
Assignee:
-
Category:
Captive Portal
Target version:
-
Start date:
06/30/2011
Due date:
% Done:

0%

Estimated time:
Plus Target Version:
Release Notes:
Affected Version:
2.0
Affected Architecture:
amd64

Description

Hi,
I've upgraded (maintaining the same configuration) a corporate firewall with a "Transit LAN" with corporate networks and a "Captive LAN" with a DesktopShare (like VNC) PC.

In the 1.2.3 pfsense version a Remote client coming from Transit LAN connects to DesktopShare PC and after authenticate himself with captive portal enabled on "Captive LAN", connect to resources.

In 2.0 version the Remote client cannot connects to DesktopShare PC. The only method to make this connection is to add in "Allowed IP address" a "TO rule" with Remote client IP.

But in this case the DesktopShare Client, after the Remote client control, is able to connect everywhere without captive authentication.

Do you know a workaround?

Actions
Copy link
 #1

Updated by Ermal Luçi almost 14 years ago

  • Priority changed from Urgent to Normal

Can you provide more information on this?
Your configuration in 1.2.3 and your config in 2.0.
Aslo an architecture of what you mean with this.

You can restrict your DesktopShare PC through firewall rules.

Actions
Copy link
 #2

Updated by Ermal Luçi almost 14 years ago

  • Assignee deleted (Chris Buechler)
Actions
Copy link
 #3

Updated by Chris Buechler almost 14 years ago

  • Status changed from New to Rejected

not a bug, fact of how CP works, that passthrough is required.

Actions
Copy link
 #4

Updated by Davide B almost 14 years ago

DesktopShare PC is restricted through firewall rules, but this rules were applied only after captive portal authentication (correctly).

Below a network/architecture "diagram" 

| Extranet Remote Client LAN | -> (FW VPN) -> (pfSense) -> |DesktopShare PC LAN| 
                                     ^            |
                                     |            v
                                 Corporate    Resources

I've an extranet VPN client (Remote client) not under my control (neither client nor Client LAN FW/Router) that must connect to my resources and i want to check the person behind the Remote client with a Radius authentication with OTP.
So, in 1.2.3 version, the Remote client connect without problem to DesktopShare PC (thanks to FW VPN ACL and pfSense ACL) and after authenticate himself with CaptivePortal enabled on DesktopShare PC LAN. This authentication enable Resources utilization.
I can't enable CaptivePortal in the Transit LAN between FW VPN and pfSense because many other Corporate Clients must use Resources without authentication provided by CaptivePortal.
With 2.0 pfSense version, Remote client cannot connect to DesktopShare PC, although they come from a LAN without CaptivePortal enabled.

The configuration is the same in the 2 different pfsense versions and there's no particular captiveportal configuration (like passthrough mac, allowed ip/hostname - although i've tried it as i've written in this issue)

I know that is a forced use of pfSense CP, but it's what I need.

Why is this a required passthrough? some sort of vulnerability?

Actions
Copy link
 #5

Updated by Chris Buechler over 9 years ago

  • Target version deleted (2.0)
Actions
Copy link

Also available in: Atom PDF