Navigation

    Netgate Discussion Forum
    • Register
    • Login
    • Search
    • Categories
    • Recent
    • Tags
    • Popular
    • Users
    • Search

    Passing client routes via Active Directory

    OpenVPN
    5
    14
    1478
    Loading More Posts
    • Oldest to Newest
    • Newest to Oldest
    • Most Votes
    Reply
    • Reply as topic
    Log in to reply
    This topic has been deleted. Only users with topic management privileges can see it.
    • O
      omnipotens last edited by

      Is there a way I can push a route based on what groups they are apart of in AD? Is there a variable visible to openvpn that allows me to see what group they are apart of where I can write a script that will pass if $group = group1 then push 10.10.10.0/24 172.16.0.1 ???

      I have different vlans within out environment and would like a easy way to add a user to one or more networks but it has to be easily managed. pfsense already has routes to allow access to each vlan but I do not want to push every route to every user.

      any suggestions

      1 Reply Last reply Reply Quote 0
      • awebster
        awebster last edited by

        You're not giving a whole lot of information to go on, but if you're using private IP space internally, then technically you only need to give out 3 routes to cover everything:
        10.0.0.0/8
        172.16.0.0/12
        192.168.0.0/16
        This will route ALL traffic to private IP space back over the OpenVPN tunnel.  What you do with it afterward is up to you.

        Caveat: It might break clients in the case where there are other private IP networks reachable where they are, but that would be the same case if you routed (all traffic) 0.0.0.0/0 to the tunnel.

        1 Reply Last reply Reply Quote 0
        • O
          omnipotens last edited by

          I don't want to pass all the routes just specific route. I want user A to access vlan A but not vlan B but I might need user C to access vlan A and B.

          Users also may need different access over time and I would like to control it with groups. I know if a user is technical enough they could add the routes by hand and still get access but really that's
          not a concern

          If I pass the whole /16 everyone would be able to see everything by default then I will need to find a way to firewall the rest which would be fine too if it could be controlled by groups.

          1 Reply Last reply Reply Quote 0
          • jimp
            jimp Rebel Alliance Developer Netgate last edited by

            If you use RADIUS auth for AD via NPS, you can pass back a reply attribute that contains routes however you like. Policies in NPS should let you set that up on a per-group basis.

            You need to setup a Cisco-AVPair reply attribute containing "route=x.x.x.x y.y.y.y" and so on.

            1 Reply Last reply Reply Quote 0
            • C
              chris4916 last edited by

              Could you please clarify something still unclear to me?

              Won't you need something like captive portal in order to manage FW rules accordingly?
              What I mean to say is that passing route definitely helps user A to reach targeted network, however, as it means that you also have FW rule allowing such access, nothing prevents, as far as I understand, user B to manually add such route and then access.
              You don't want B to access but you can't prevent it unless you set up something specific isn't it?

              1 Reply Last reply Reply Quote 0
              • D
                doktornotor Banned last edited by

                Yeah exactly, this just doesn't make sense. Set up different OpenVPN servers for different user groups that have different access needs to that you are actually able to manage firewall rules per VPN.

                1 Reply Last reply Reply Quote 0
                • C
                  chris4916 last edited by

                  @doktornotor:

                  Yeah exactly, this just doesn't make sense. Set up different OpenVPN servers for different user groups that have different access needs to that you are actually able to manage firewall rules per VPN.

                  This is more or less what I meant.
                  Well, one may have slightly different needs. f.i. 2 sites connected though VPN link (site-to-site) plus willingness to control routing "per user". But in such case the "adding route" question is not valid.

                  Definitely requirements should be refined.

                  1 Reply Last reply Reply Quote 0
                  • jimp
                    jimp Rebel Alliance Developer Netgate last edited by

                    You can also push static addresses and firewall rules from RADIUS.

                    But ultimately having separate VPNs is easier.

                    You can setup multiple LDAP server entries each with a different extended filter to restrict by AD group and select the appropriate auth server for each VPN as needed.

                    1 Reply Last reply Reply Quote 0
                    • C
                      chris4916 last edited by

                      @jimp:

                      You can also push static addresses and firewall rules from RADIUS.

                      Would you mind elaborating on this please? Do you mean IP allocated by VPN server? and what's about FW rules?
                      I'll look at this, for my own understanding  ;)

                      1 Reply Last reply Reply Quote 0
                      • jimp
                        jimp Rebel Alliance Developer Netgate last edited by

                        Our OpenVPN code supports pulling in a few bits and pieces from RADIUS if you know the right incantations :-)

                        Most are Cisco-AVPair style:

                        • Cisco-AVPair inacl= / outacl=  – firewall rules, simple syntax like "permit tcp from foo to bar", I don't think we have a formal write-up on the syntax but it shouldn't be hard to nail down.
                        • Cisco-AVPair dns-servers= -- space-separated list of DNS servers
                        • Cisco-AVPair route= -- as mentioned above, a way to push a route from RADIUS, syntax is just "x.x.x.x y.y.y.y" where the first is an IP addr, second a subnet mask
                        • Framed-IP-Address= -- an address to push to the client, server will be one address lower than the IP address given, e.g. if you want the client to use x.x.x.4/30 (client is .6, server .5) then pass along x.x.x.6 to the client
                        1 Reply Last reply Reply Quote 0
                        • C
                          chris4916 last edited by

                          Thanks a lot Jimp. Very helpful  8)

                          1 Reply Last reply Reply Quote 0
                          • O
                            omnipotens last edited by

                            Thanks for all your help.  And having separate VPNs does not make it easier when your dealing with couple of hundred users and around 50 different networks. That and some of these users needs access to separate environments and that would require them to disconnect and connect. Being able to push routes as well as firewall rules via a group is the preferred method. Then I can set it up and forget and let someone else manage the groups. That and we can have one client to manage not having to deal with many different configs.

                            1 Reply Last reply Reply Quote 0
                            • D
                              doktornotor Banned last edited by

                              Your problem to deal with. All we are telling you that this does not produce any real security.

                              1 Reply Last reply Reply Quote 0
                              • O
                                omnipotens last edited by

                                I would like to thanks everyone for the help I was able to get working exactly what I wanted by having radius push routes and firewall rules all managed from AD. Thanks Again

                                1 Reply Last reply Reply Quote 0
                                • First post
                                  Last post

                                Products

                                • Platform Overview
                                • TNSR
                                • pfSense Plus
                                • Appliances

                                Services

                                • Training
                                • Professional Services

                                Support

                                • Subscription Plans
                                • Contact Support
                                • Product Lifecycle
                                • Documentation

                                News

                                • Media Coverage
                                • Press
                                • Events

                                Resources

                                • Blog
                                • FAQ
                                • Find a Partner
                                • Resource Library
                                • Security Information

                                Company

                                • About Us
                                • Careers
                                • Partners
                                • Contact Us
                                • Legal
                                Our Mission

                                We provide leading-edge network security at a fair price - regardless of organizational size or network sophistication. We believe that an open-source security model offers disruptive pricing along with the agility required to quickly address emerging threats.

                                Subscribe to our Newsletter

                                Product information, software announcements, and special offers. See our newsletter archive to sign up for future newsletters and to read past announcements.

                                © 2021 Rubicon Communications, LLC | Privacy Policy