Hello,
> I had not seen that thread, but it's nice to see someone read the
Gigabit article I once wrote ;)It`s hard to miss when using "openvpn speed
test" as a search term :)Nice article, very useful.
> as for client-to-client: yes, an extra decrypt+encrypt is necessary,
as the encryption keys are derived for each client. Thus , with
> client-to-client enabled the flow would be:
> client1:tun --- internet ---- server:tun -> openvpn decxr+encr
-> server:tun -------- internet ---- client2:tunThat`s clear, thanks, and I
think I will discover that throughput will go down.How about my test scenario
which is not using client-to-client?
> the biggest bottleneck in all this is the fact that packets are only
1500 bytes long - again, if you increase the tun-mtu to 9000 the
> performance will go up.As you wrote in the Gigabit article that won`t
probably help over WAN.In the end this pfSense box has to end up at the front
door.O.T.I read that some voices speak that MTU should be increased because
links are getting faster, maybe in the long run that`s a good idea.
> It is also worthwhile adding
> snd-buf 0
> rcv-buf 0
> to the Linux client and servers, as that can boost performance a
little bit.
Actually I did, it had little effect on throughput.But a while ago I tested
this on my NAS and there it did improve setting 393216. Waiting time to have
time to test more :)Thanks,Pippin
------------------------------------------------------------------------------
Find and fix application performance issues faster with Applications Manager
Applications Manager provides deep performance insights into multiple tiers of
your business applications. It resolves application problems quickly and
reduces your MTTR. Get your free trial!
https://ad.doubleclick.net/ddm/clk/302982198;130105516;z
_______________________________________________
Openvpn-users mailing list
Openvpn-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-users
