natemtso
Is there anything that I should specifically consider when deploying a multi-tenant environment that needs to prevent customer to customer interaction? Some of the obvious things we have handled, i.e. we have done the following:
1.) Configured in routed mode (tun) to avoid layer 2 attacks like ARP poisoning.
2.) Configured with client-to-client turned off to avoid client to client attacks or DHCP spoofing attacks, etc.
3.) Leverage IP Tables and virtual IP address ranges to protect internal and customer resources.
4.) Use TLS Auth to prevent mitm attacks.
5.) Use Dual Factor Authentication to authenticate clients (via PAM modules).
6.) Use UDP connections to help avoid DoS attacks.
7.) Unprivileged mode to protect the *Nix OS.
8.) Larger RSA and Symmetric keys.
9.) Using a CA and an Intermediate CA.
10.) Fully patched OpenVPN and OS.
My biggest concerns are that there is potential for one customer to interact with other customers, or with other customers VPN exposed services (such as databases). The key attacks I'm looking to protect against are things like IP address/MAC spoofing, DHCP spoofing, ARP spoofing, anything that could yield a redirect of customer traffic to a customer or allow bypass of IP tables filters we use to protect customer services.
I noted the float option, but don't have a complete understanding of what it does.
--float
Allow remote peer to change its IP address and/or port number, such as due to DHCP
(this is the default if --remote is not used). --float when specified with
--remote allows an OpenVPN session to initially connect to a peer at a known
address, however if packets arrive from a new address and pass all authentication
tests, the new address will take control of the session. This is useful when you
are connecting to a peer which holds a dynamic address such as a dial-in user or
DHCP client.
Essentially, --float tells OpenVPN to accept authenticated packets from any
address, not only the address which was specified in the --remote option.
My concern with this is that if we support a multi-tennant environment, we want to prevent changing of IP addresses on the client side of our tunnel. It seems like if this is enabled, IP addresses on the client side of the tunnel could be changed. Is that accurate? I've been unable to make this happen in my testing, but it is a concern.
natemtso
Hate to bump myself, just wondering if anyone has any thoughts on this. Holiday season and all, maybe it dropped down the list.
