Anonymous | Login | 2024-12-04 09:39 EST |
Main | My View | View Issues | Change Log | Roadmap |
View Issue Details [ Jump to Notes ] | [ Issue History ] [ Print ] | |||||||
ID | Project | Category | View Status | Date Submitted | Last Update | |||
0001035 | PacketFence | captive portal | public | 2010-07-21 13:57 | 2011-01-26 15:42 | |||
Reporter | obilodeau | |||||||
Assigned To | obilodeau | |||||||
Priority | normal | Severity | feature | Reproducibility | N/A | |||
Status | closed | Resolution | fixed | |||||
Platform | OS | OS Version | ||||||
Product Version | ||||||||
Target Version | Fixed in Version | 2.0.0 | ||||||
Summary | 0001035: Captive portal should be able to capture clients using a proxy | |||||||
Description | If - 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 | |||||||
Tags | No tags attached. | |||||||
fixed in git revision | ||||||||
fixed in mtn revision | 074427d6f4c16da5a8f9ef52b6751e87eb9507c4 | |||||||
Attached Files | ||||||||
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 |