2017-10-03 0:55 GMT+05:00 Xen <l...@xenhideout.nl>:
> I am sorry this will be my last message.
>
> This is bullshit.
>
> Илья Шипицин schreef op 02-10-2017 21:26:
>
> yes, if you distribute all of your organization routes via DHCP - it is
>> good.
>> but it is not common practice
>>
>
> Then you throw away a solution just to be able to call something else bad.
>
I did not say it is bad.
usually, you do not distribute all the routes via DHCP, just default route.
yes, you can distribute all the routes via DHCP, but, for example option 121
Windows clients will get it. not sure about the rest (smartphones, linux,
osx, ...)
>
> If it is common practice not to build any railroads, then suddenly trains
> seem like a bad solution.
>
> If all of your company's subnets are on a single segment, ie. 192.168.X.0
> then you can reach all of them with 192.168.0.0/16.
>
> You would probably only require one additional route in addition to your
> default route.
>
> And this is only required for VPN clients; ie. probably only those laptops
> people bring in.
>
exactly
>
> So if the cost of this solution is to give every VPN client (if that's
> possible) one extra route then that's not a huge cost to pay if the only
> concern is that those laptops can reach other floors through the normal
> gateway instead of the VPN server that is sitting right next to it...
>
> Which is probably not a huge problem to begin with...
> ...and if the solution only targets VPN laptops, then it seems also a fine
> solution to me.
>
> It is clear the problem is solvable...
>
> Saying "Yeah but it is not perfectly ideal" doesn't mean much.
>
> The alternative is having no automatic VPN login,
>
> Or Windows scripting to make choices based on what network one is in,
> which requires a lot of development, installation on every laptop, and so
> on.
>
> You will need to build your own Windows client, preferably not just a
> script. It will have to run as a Windows service.
>
> Doable if you can make it a nice thing. Then it can also perform the
> function of selecting the nearest server.
>
> But you won't have this done in 30 hours.
>
> So dispensing one extra route to VPN clients (could simply be based on
>
MAC addresses?) seems a very easy short-term solution that requires less
> maintenance until you have a fully-fledged service you can deploy in an
> automated fashion, then it doesn't... matter anymore as much, but a
> server-based solution is still a better choice I feel.
>
> You could also only dispense this route to Wifi clients for instance.
>
> It is zero configuration on the client, if you give it to wifi clients it
> is easy on the server, if you don't you require maybe a database of MAC
> addresses.
>
> And for no other reason than to reach other floors a little bit more
> efficiently.
>
it depends on how powerful is vpn server.
assume it is 1Gb, and there are 100+ users per floor with SMB traffic.
>
> Deploying a centrally distributed service for installation on all laptops
> is a long term goal.
>
> This solution however you have implemented in a day.
>
> If it's not common practice, it can become one. ( I mean what is that for
> kind of retort? ).
>
> Become equivalent and can compete in terms of metric.
>>>
>>
> it is equivalent in terms of metric, however, next floor is better to be
>> accessed via local gateway, not a vpn gateway
>>
>
> No I did not say it was equivalent in terms of metric.
>
------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
Openvpn-users mailing list
Openvpn-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-users
