Here is what I need to accomplish:
+---------+-------- Customer VPN 1 |Corporate|-------- Customer VPN 2 Internet -----------|Firewall |-------- Customer VPN ... +---------+-------- Customer VPN N | | +---------+ |pfSense |-------- Server LAN |Firewall |-------- Lab Network +---------+-------- Dev Wireless Network | | Developer Network
I need to ensure that any user from "Developer Network" or "Dev Wireless Network" is authenticated by their Active Directory username/password and be in a specific AD group before they can access any of the "Customer VPN" networks and allow them unauthenticated access to the Internet and internal sites. I'd prefer to do this at the pfSense rather than our already overloaded Juniper corporate firewall. I'd considered putting Dante or another socks proxy on the pfSense but that implies putting socks clients on all the systems.
Can someone suggest a better way of doing this?
Sounds like you need to implement 802.1X in order to achieve this… way beyond the realm of a forum IMHO.
Am I correct guessing you have 2 different questions here:
- one about VPN access
- one other (and different BTW) about internet access through HTTP proxy
I already have a Squid HTTP proxy running on the pfSense and it works fine though I need to take it out of transparent mode and set up a proxy config for this now. That part I have a handle on without issues.
My issue is that I also need telnet, and ssh access to be authenticated before allowing it outbound to the customer VPNs. The customer VPNs are site-to-site VPNs from our corporate firewall and aren't at issue here. What is the issue is limiting access to them from our development networks behind the pfSense allowing only authorized users to do telnet, ssh, http and https outbound to those networks.
The ideal solution would be something like:
Source: Development networks
Dest: Customer VPNs
Services: SSH, Telnet, HTTP, HTTPS
Auth Server: Development AD Server, Group "Customer Access"
Does that make more sense?
I'm also looking at ways to do this on our corporate firewall but it has its own set of issues with doing that.
Sure it does ;)
As you have now explicit proxy with (soon) authentication and profiling, wouldn't captive portal do the trick ?
Users will have to authenticate first at captive portal level and this will grant them for access through local FW.