Securing multiple interfaces from each other - access rules
-
It's probably a bad way to word the title but I'm stuck and not sure what my options are.
I've got a development network that is brutally mixed. I've got some projects that have their own firewalls, some have their own interface off my pfSense just to compartmentalize them and others just have a single box that hangs out on my LAN.
I've got an interface just for clients that pfSense does the DHCP for, I have another interface that I hung an OpenVPN server off of which then has access to the LAN from within the IP block the server hands to clients.
But all of the access between interfaces at this point is IP or entire interfaces only. Meaning, the CLIENT interface has an all access pass, the DMZ interface can go nowhere but certain IPs have pinholes to get to things like LDAP and web servers to databases, etc…
To top it off, it's all a mix of Windows and Linux, again depending on the project's needs/environment and these are all standalone with no central authentication.
What we're looking for is if a computer plugs into the CLIENT network (or if they come over the OVPN connection) I need to figure out what they're supposed to have access to. In other words, their traffic will be allowed to the interface(subnet) that holds project X, but block them from project Y. Whether this is done via destination IP and/or entire subnets, interfaces, etc... the more options the better. I'm looking more for just blocking traffic based on where you're allowed to go (say based on group membership and an ACL) vs. tying every server into a single central auth; mostly due to the jumbled mess that each project tends to be with wildly varying requirements.
Looking around I'm seeing references to RADIUS, some to captive portal and 802.1. I'm not sure if any or all of these are part of the answer but it seems like the right direction; or I'm horribly off and there is no way to do this.
The users' equipment is not part of an AD, but I do have one I set up for authentication for access to systems that I was able to get plugged into it (code repository, OVPN, and so on). My point is there is no 'login' currently to this development domain as all the computers are either corporate (with its own domain) or are bought specifically for the project.
I realize this is a huge thing but I need to know enough about what needs to be done to tell management they either stick with the all in way we have things now or we hire a pro to get it set up correctly (and get hardware/licensing if needed).
So is this even possible or a fool's errand?
Thanks for your time.
-
Hmm,
that's a big question and I am sure I did not catch all.
RADIUS and CP will probably not help you. CP is just for allow access to the (V)LAN or not.I would suggest to use a switch which can do dynamic VLAN assignment. Then connect the switch with a RADIUS server and do a simple authentication based on MAC address. based on the MAC address the switch/RADIUS will put the clients into their "correct" VLAN. Then you define firewall rules for every VLAN. The MAC address authentication has the advantage that you do not need to install any certificate on the clients or someone has to enter a username/password.
Another possibility could be - to add all clients static on your DHCP. perhaps build groups - lets say:
192.168.10.10 - 192.168.10.29 group1 - all hosts of project1
192.168.10.30 - 192.168.10.59 group1 - all hosts of project2
192.168.10.60 - 192.168.10.89 group1 - all hosts of project3So these hosts will always get the "correct" IP defines by your DHCP.
Then put these IP ranges in an Alias - this allows you to create firewall rules based on these aliases as source address.Not sure if this will help you but for me it is difficult to imagine your network map and what is happening there ;-)
-
Thanks Nacht,
The problem is, the network is an ongoing disaster. It's contracting work so we've got a company office with say 10 different projects at any given time, some come, some go. None of them can be forced into a certain toolset as they may be pickup contracts from incumbents so the folks on them have to use what comes in. It all started as a simple idea to centralize certain services that got wickedly complicated as new projects came in.
Sometimes the contract has hardware, other times they just need a web and database server so it's hosted on the 'shared' server and sometimes they don't need anything but a laptop to code on and the code repo to store it in.
The simplest analogy I can give is a hub and spoke. In the hub is core services and connectivity like the client interface with DHCP, the LAN interface with code repository and bug tracking servers and all of the mixed projects with minimal needs. The spokes are entire projects with their own subnet or interface that the CLIENT network needs to route to for testing or code uploading or configuration (RDP or SSH). Some of the spokes are literal interfaces off my pfSense, others are networks off in the DMZ because they need public routing for testing and they have their own firewall, I only do routing/edge for them.
What you're suggesting would kind of get me there but there's one key point I failed to mention: Developers move around and sometimes are working on multiple projects at the same time.
One thing I was thinking was, since I don't have everyone actually auth'ed, ditch the CLIENT interface (or give it no routing) and force everyone to use OVPN. Right now I'm using a single shared key and everyone authenticates against the AD but if needed I can do individual certs if it gets me control somehow over where they're allowed to go; best case at the firewall or network level, worst case OVPN and what routes it pushes down.
-
If everyone is connecting via OpenVPN then you can route all networks to the VPN users.
Then you can use the "client specific override" to force a VPN client to always get the same OpenVPN IP/subnet.
This OpenVPN subnet can be used to create firewall rules.Every OpenVPN connection consits of 4 IPs or a /30 subnet.
This can be used as source IP on the firewall. If you install OpenVPN on pfsense then you get a new tab "OpenVPN" on the firewall GUI.
But forcing all traffic through OpenVPN with good speed will cost more CPU power than without any encryption.But I am not sure if this will make your firewall ruleset easier/better and give your more conrol on where these hosts can connect to.