Greetings,
So I did some testing with forwarding rules in place. Still having a bit of
trouble understanding why it's not working. As David recommended, I used
the wiki page here as a reference:
https://community.openvpn.net/openvpn/wiki/BridgingAndRouting. The section
"Using routing and OpenVPN not running on the default gateway" is more the
type of setup I have.
The setup is a test machine in AWS EC2 with a dedicated Elastic IP in a VPC
environment. I turned off source/destination check in the AWS console so
that it's not blocking packets not intended for/originating from the test
VPN machine.
OpenVPN config file:
https://gist.github.com/sc250024/f115b1638180e337bf79b0a7a87d6288
Client-connect script:
https://gist.github.com/sc250024/93da38dbc6fc4e317a901004ddfcfcce
Server IPTables commands, output, and server networking information:
https://gist.github.com/sc250024/1799754356170a0d000740a25cc74512
Client networking information:
https://gist.github.com/sc250024/2f154068a42db0ca682c2dcf915e934f
TCPDump from VPN server of connected client trying to reach a server they
have access to over VPN:
https://gist.github.com/sc250024/12e226a2dae7126a3c13074f4e6fbabb
<https://gist.github.com/sc250024/12e226a2dae7126a3c13074f4e6fbabb>
The process is:
1. User connects via TCP (for now), and receives two routes from
`client-connect` for servers they can access; no Internet traffic goes
through the VPN
2. IPTables rules are setup on the server side to forward from the user's
VPN DHCP IP address to the servers they can access.
3. On the client computer, client runs a `telnet 10.0.31.7 22` or `telnet
10.0.10.107 22` to check if they have connectivity to those servers.
4. In the FORWARD chain, the rules are being hit correctly (you can see
packets in the counter) but the telnet commands above are not working.
Did I miss something in the iptables commands?
On Thu, May 19, 2016 at 8:40 PM, Scott Crooks <scott.cro...@gmail.com>
wrote:
> 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
>
--
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
