On Thu, Aug 02, 2018 at 04:05:24AM +0000, Lucas Rolff wrote: > Hi michael, > > Without the send-proxy, the client IP in the export would have to be the > haproxy server in that case right?
That's it. But Michael is absolutely right, your NFS server doesn't support the proxy protocol, and the lines it emits below indicate it : Aug 01 21:44:44 nfs-server-f8209dc4-a1a6-4baf-86fa-eba0b0254bc9 kernel: RPC: fragment too large: 1347571544 Aug 01 21:44:44 nfs-server-f8209dc4-a1a6-4baf-86fa-eba0b0254bc9 kernel: RPC: fragment too large: 1347571544 Aug 01 21:44:44 nfs-server-f8209dc4-a1a6-4baf-86fa-eba0b0254bc9 kernel: RPC: fragment too large: 1347571544 Aug 01 21:44:45 nfs-server-f8209dc4-a1a6-4baf-86fa-eba0b0254bc9 kernel: RPC: fragment too large: 1347571544 This fragment size (1347571544) is "PROX" encoded in big endian, which are the first 4 chars of the proxy protocol header :-) > The issue there is then, that I end up with all clients having access to > haproxy can suddenly mount all shares in nfs, which I would like to prevent Maybe you can modify your NFS server to support the proxy protocol, that could possibly make sense for your use case ? Otherwise on Linux you may be able to configure haproxy to work in transparent mode using "source 0.0.0.0 usesrc clientip" but beware that it requires some specific iptables rules to divert the traffic and send it back to haproxy. It will also require that all your NFS servers route the clients via haproxy for the response traffic. This is not always very convenient. Regards, Willy
