On Wed, May 18, 2016 at 09:28:55AM -0700, Scott Crooks wrote: > In order to avoid spamming this list with unrelated questions about > IPtables commands, I'm wondering is there is a book/resource that > anyone knows of that tackles how to do more advanced setups with > OpenVPN and IPtables?
In terms of dead trees, I doubt it. > It seems there are many examples on the Internet of "redirect all > traffic to OpenVPN, then masquerade (NAT) on the server" but I'm > looking to do something more advanced than this. I purchased > "Mastering OpenVPN" and have a test setup that does the following: > > - Authenticates users via LDAP > - Pulls access rights for the user from LDAP > - Pushes per user routes via the `client-connect` script > - Does not route all Internet traffic You did not really say what kind of resources you're wanting to provide to the VPN users. > The part I'm missing is the server-side IPtables rules. Each user > should get their own chain, created when they connect, and > subsequently deleted when they disconnect. Things become unclear > when trying to figure out OpenVPN in relation to netfilter hooks. You also didn't say what kind of restrictions you wish to place on your VPN users. > Specifically: > > - At what point in the netfilter hook process does traffic get > decrypted? No. That happens before the kernel sees anything. The openvpn process running in userspace receives and decrypts traffic which is then passed to the kernel's tun driver. You can't know what's in a tunnel packet before decryption. After decryption, it's in the tun interface, which is just another interface to the kernel, nothing special. NOTE: if --client-to-client is set, the tun driver (and as a consequence, all of Netfilter) is bypassed. So if you plan to apply firewall rules to VPN clients, you must not set --client-to-client. > - Is the FORWARD chain the best way to process per user access rules? Packets which are forwarded *only* go to the FORWARD chain in the filter table. Yes, the openvpn tunnel traffic comes in INPUT, and traffic connecting to services on the VPN server itself will also go to INPUT. So the answer is, "Maybe, you didn't say enough." > - Is there a way to NOT masquerade traffic from the OpenVPN server, I have no clue where you got the idea that masquerade was required. Source NAT is only necessary when connecting RFC1918 networks to the Internet. Assuming that you're using an RFC1918 netblock for VPN clients, you still only need NAT if you're planning to pass traffic out to the Internet. What you have said implies that this is not the case. > and make it appear that traffic comes from the same subnet > configured in the `server` directive? A VPN client connecting to resources which should be routed through the VPN will set its source IP address to the address assigned through openvpn. Again, I'm not sure what you're thinking. > Many questions I know. Basically looking for a book/resource so I can > answer them myself :) On freenode IRC, the #openvpn channel has a bot with some good self help factoids. I think maybe you want !serverlan, but I can't tell from what you have said. The #netfilter channel has good information in the /topic on general best practices. I'm not sure that the per-user chain sounds like a good idea, but again, it's hard to say. I'm always in #Netfilter and sometimes #openvpn also. -- http://rob0.nodns4.us/ Offlist GMX mail is seen only if "/dev/rob0" is in the Subject: ------------------------------------------------------------------------------ Mobile security can be enabling, not merely restricting. Employees who bring their own devices (BYOD) to work are irked by the imposition of MDM restrictions. Mobile Device Manager Plus allows you to control only the apps on BYO-devices by containerizing them, leaving personal data untouched! https://ad.doubleclick.net/ddm/clk/304595813;131938128;j _______________________________________________ Openvpn-users mailing list Openvpn-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/openvpn-users