|
|
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi there, first of all, thanks for the reponses. Charles Duffy wrote: > I use dynamic DNS. > > Let each OpenVPN server have its own, separate pool of IPs. When a > client connects, it gets an IP on whichever pool is appropriate to the > server it connected to; each server of course has a route to the other > one, so clients can talk between servers. > > DNS is dynamically updated with both forward and reverse routes for > freshly connected clients, so pinging userfoo.vpn.mycompany.com will > always reach userfoo, no matter which VPN server they're on (and thus > which pool the address in question is taken from). Yeah, thats one of the ways i've taken into account for that. But some problem remains: Due to the complexivity of the networks put together with the vpns we also have a couple of firewall rules based on the client. At first we updated the complete ruleset on a regular basis. Now we're planning about getting the rules and stuff for every user via. the client connect script from our ldap (thats how we do it with some other vpn soft.. the business expensive shit ones ;-) But i noticed a small issue with that: when a client disconnects (win client, linux server, udp mode), the server didn't notice that... it will run into the timeout. This might be ok, but with multiple servers this break things cause you might guess, the client appears on multiple servers (cause its connection isn't closed on the old server yet). For now we played with rejecting new connections when the old one is still 'there' but this is annoying for the users :( > If the client has a network behind it you're also exposing to the VPN, > maybe. Otherwise, no -- the route to the client is implied by which pool > its address is taken from, so you just have one route to the other VPN > server that's applicable to its entire IP pool. Yeah, we do this nasty stuff. ;) We're around 100 locations with local networks connecting to the gateways and they need to communicate to eachother. So this might be a bit of.. guess? work, right ;) > If you have networks behind your clients you need to route to through > the VPN (and, again, if you don't then there's no need for any of this > funkiness), you might consider a fancier client-connect script, one > capable of doing actual *synchronization* between the current routing > table and the remote server's VPN client set. It'd take a little bit of > doing, but I don't see such a script as being excessively tricky. Well, the easy-hack was done in one day, but it has some faults (like mentioned above, the problem with the multiple connects per client on different servers). Thats why i asked if someone knows a maybe better way doing this. Acutually the project isn't in a hurry, and due to a limited time, i cannot play around with other solutions like a bgp-like way to get the routing to work but i'll keep you informed which way we'll finally go ;) Thanks, Sven -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.2 (GNU/Linux) iD8DBQFDbM0HQoCguWUBzBwRAssmAKCig2jVNE7xEm4uW2bXO7VUQ2tuxQCfZZ0Y uUqGSFyDAKk0lnNxavJtCek= =zS/j -----END PGP SIGNATURE----- ____________________________________________ Openvpn-users mailing list Openvpn-users@xxxxxxxxxxxxxxxxxxxxx https://lists.sourceforge.net/lists/listinfo/openvpn-users |