Rob/David,
Thanks for the reply, and your patience, it was informative. To clarify, my
OpenVPN solution is routing FROM RFC 1918 addresses TO RFC 1918 addresses.
The user connected to the VPN doesn't actually route any Internet traffic.
I am dynamically pushing routes using the `client-connect` hook in OpenVPN
to the user. Those routes are internal addresses inside the datacenter
where the OpenVPN server sits. The user's default gateway is unchanged, and
if they need specific access to internal resources, only that goes through
OpenVPN.
"FORWARD simply means that packets arrived via network and are routed to
depart via network. They are not destined to nor originated from local
sockets."
Then it seems that's the path to go. Once connected, any packets being
passed to the OpenVPN server are not for anything on the OpenVPN server
itself. The OpenVPN firewall is simply restricting access to what that
specific user can access, and blocking anything the user shouldn't access.
This way, a user couldn't change the routing tables on their local
computer, and access something they're not allowed to access.
On Thu, May 19, 2016 at 5:11 PM, /dev/rob0 <r...@gmx.co.uk> wrote:
> Comments to both posters inline ...
>
> On Fri, May 20, 2016 at 12:42:31AM +0200, David Sommerseth wrote:
> > On 19/05/16 20:47, Scott Crooks wrote:
> > > Thank you also for the explanation regarding the firewalling.
> > > Part of the problem (and why I didn't reply to /dev/rob0) is
> > > because when it comes to iptables, I "don't know what I don't
> > > know" if that makes sense. It's hard to specify what I'm going
> > > for since there's a multitude of ways to do it I'm sure. However,
> > > if using the FORWARD chain can allow a user to have access to
> > > only what they need, and avoids having to use NAT, then that
> > > sounds like the way to go! Thank you again.
>
> FORWARD simply means that packets arrived via network and are routed
> to depart via network. They are not destined to nor originated from
> local sockets.
>
> FORWARD does not avoid NAT. You avoid NAT by not routing packets
> from RFC 1918 addresses to the Internet and vice versa, not routing
> packets from the Internet to RFC 1918 addresses.
>
> Most NAT traffic does in fact go through filter/FORWARD.
>
> > Yes, that should work.
>
> ... unless the particular traffic in question does not go to FORWARD,
> such as if a VPN user is connecting to / restricted from services on
> the VPN server itself.
>
> > Again, please have a look at the firewall
> > configuration documentation in eurephia. The key concept between
> > what you describe and what eurephia does is quite similar, so you
> > might get some ideas from there:
> >
> > <
> http://www.eurephia.net/documentation/eurephia/1.1/html/Administrators_Tutorial_and_Manual/chap-Administrators_Manual-FWintegration_Chapter.html
> >
> >
> > What is not described there is the magic eurephia does to update
> > iptables on-the-fly when clients connect and disconnect. But in
> > essence that is eurephia running iptables commands updating the
> > 'vpn_users' table. However, beware that OpenVPN needs to run with
> > root privileges to be able to update iptables on the fly. And that
> > is one of the reasons eurephia will fork out a sub-process during
> > the init phase which keeps root privileges and gets limited update
> > requests from the unprivileged openvpn process (after it has
> > dropped privileges etc).
>
> This sounds like eurephia could benefit from the use of ipset(8) and
> the "set" match. You don't necessarily need to be root to update
> ipsets. And even if you are or do need root, it's a more sane way to
> manage the ruleset than adding & deleting rules.
>
> Oh, Scott: I saw your note in IRC, but I wasn't there when you were.
> --
> 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
>
--
Scott Crooks (王虎)
LinkedIn: http://www.linkedin.com/in/jshcrooks
------------------------------------------------------------------------------
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
