PacketFence
Bug Tracking System
Main | My View | View Issues | Change Log | Roadmap
  

View Issue Details [ Jump to Notes ] [ Issue History ] [ Print ]
IDProjectCategoryView StatusDate SubmittedLast Update
0001035PacketFencecaptive portalpublic2010-07-21 13:572011-01-26 15:42
Reporterobilodeau 
Assigned Toobilodeau 
PrioritynormalSeverityfeatureReproducibilityN/A
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Version 
Target VersionFixed in Version2.0.0 
Summary0001035: Captive portal should be able to capture clients using a proxy
DescriptionIf
- clients run a proxy specified by domain name (not hardcoded IP)
- port of the proxy is known
Then we could configure a special means to allow the captive portal to work with such an environment.

I was able to do a quick proof of concept that worked but there are issues with SSL and having the original IP address of the source user.

Here's the story:

Apache is configured to act as a proxy on port 8080 and supports both HTTP and HTTPS proxying (through HTTP CONNECT). The downside of proxying is that the IP address of the source is hidden by the proxy and this IP is required by the portal to be able to find the MAC address of the user. As a workaround the proxy uses rewrite rules to append the source IP to the captive portal redirect. Several web pages were modified to fetch the IP in URL parameters if the direct IP was 127.0.0.1.

Current limitations of this solution:
- If the first request through the proxy is HTTPS then appending the IP to the URL is not possible. In that case, an error saying “Please disable your proxy” is shown to the user.
- Having the IP in the URL is something that could be tampered with by the client-side. This is not acceptable.
- PHP-based pages (remediation) is not able to access the IP stored in cgi session

Steps for correct implementation:
1. Either:
  a) Drop SSL/TLS for proxy capture (easiest because IP could be added in HTTP Headers)
  b) Use another proxy server that would store the IP source out of band
  c) Do SSL proxying since we already have access to the private key
  d) Rewrite the CONNECT request (is it possible even?)
  e) Keep same approach but IP in a cookie and encrypt it (would need to confirm if it's doable)
2. Modify web registration and isolation pages to be able to find the IP that is behind the proxy in a clean way
TagsNo tags attached.
fixed in git revision
fixed in mtn revision074427d6f4c16da5a8f9ef52b6751e87eb9507c4
Attached Files

- Relationships

-  Notes
(0001712)
obilodeau (reporter)
2010-10-04 17:12

 After a lot of different attempts to get this to run, I think the squid + ssl_bump is probably the most likely to succeed so I'm heading in that direction.
(0001713)
obilodeau (reporter)
2010-10-05 12:24

 Squid + SSL-Bump + Redirectors did the trick.

Writing some doc and making the required changes to the codebase (ie: ip lookup)
(0001714)
mattgriffiths (reporter)
2010-10-06 03:26

 Good decision. I was going to suggest you try x-forwarded-for insertion to get the ip address into the header of the connect request. mod_proxy looks as though it will do this under certain circumstances but I've never used it.

Making the move to squid also offers you the opportunity to interact with client machines that are configured to use explicit IP addresses as proxy. If Packetfence users have routers in their networks that support wccp it's possible to make arbitrary tcp connections on any port / IP arrive at squid over a GRE tunnel from the router.

If you're interested in playing with wccp I've got some working squid / cisco IOS / centos 5.5 configs I can share.
(0001715)
obilodeau (reporter)
2010-10-06 09:36

 Yes, the x-forwarded-for is added even in the case where we tried to reach an SSL site in the first place (in this case there is a certificate warning on the client obviously). The ssl-bump decrypts the traffic and appends the x-forwarded-for locally before sending it to PacketFence's apache on the machine itself.

Thinking about an 'IP-based proxy' problem, I was thinking about the following approach: since PF is the default gateway of registration / isolation. We could use iptables to terminate/rewrite packets with the proxy's IP at the destination. In DHCP mode it's how things work.

But then this wouldn't work on a routed isolation / registration environment. Which is what most large networks do now.

So, yes, I am interested by the wccp config you've built! :)
You can email them to me or, better yet, share them on the -devel mailing list (making sure you strip out confidential information).
(0001716)
obilodeau (reporter)
2010-10-06 12:17

 Pushed new feature in trunk.

Requires squid and is not useful to everyone so it is in addons/ but it's trivial to install.
- squid config + redirector script
- Provided requirements, install instructions and basic troubleshooting.
- IP lookup code updated in core

- Issue History
Date Modified Username Field Change
2010-07-21 13:57 obilodeau New Issue
2010-07-21 13:57 obilodeau Status new => assigned
2010-07-21 13:57 obilodeau Assigned To => obilodeau
2010-10-04 17:12 obilodeau Note Added: 0001712
2010-10-05 12:24 obilodeau Note Added: 0001713
2010-10-06 03:26 mattgriffiths Note Added: 0001714
2010-10-06 09:36 obilodeau Note Added: 0001715
2010-10-06 12:17 obilodeau mtn revision => 074427d6f4c16da5a8f9ef52b6751e87eb9507c4
2010-10-06 12:17 obilodeau Note Added: 0001716
2010-10-06 12:17 obilodeau Status assigned => resolved
2010-10-06 12:17 obilodeau Fixed in Version => trunk
2010-10-06 12:17 obilodeau Resolution open => fixed
2010-12-15 11:37 obilodeau Fixed in Version trunk => 2.0.0
2011-01-26 15:42 obilodeau Status resolved => closed

Copyright © 2000 - 2012 MantisBT Group
Powered by Mantis Bugtracker