Thanks for explaining it Andrew. My guess is the same -- it's to do with cloud routing/networking, but the cloud hosting company says that their infrastructure and equipment have no restrictions in place, and tunneling should work fine.
>> Could you test using a proxy style load balancer? That way, the >> inbound and reply traffic would all match up nicely. If that works, it >> would prove that your setup is sound and working and would narrow down >> the problem to being TUN specific. For a test, HAProxy is a great >> FLOSS proxy style load balancer. I just tried HAProxy to load balance to the same real-server, and it works fine. I don't mind using HAProxy for my requirements, but an LVS tunnel seemed interesting because the real-server could respond back directly to the client, bypassing the load balancer. Cheers, Nick On Tue, 31 Mar 2020 at 22:22, Andrew Howe <andrew.h...@loadbalancer.org> wrote: > Hi Nick, > > > There's no firewall in-front of the real server, while I'm testing LVS. > > There should be router I'm guessing. As this a cloud hosted VM, I checked > > with the hosting company, and they've confirmed that their network > > equipment is not configured to drop any packets, and tunneling should > work > > fine. > > Being in the cloud changes things. Not having access to the underlying > infrastructure, to make configuration changes and perform > troubleshooting, may make using LVS/TUN impossible. > > Whatever the service provider has sitting at the edge of their/your > network is surely providing at least a basic level of security. Even > if there's just a simple router that is tracking connection states at > the edge it would surely drop the reply traffic from your real server. > > Inbound packet: > Source = Load balancer's public IP address > Destination = Real server's public IP address > > Whatever is sitting at the edge will forward the inbound packet to the > real server and will start tracking this as a new connection. > > Reply traffic: > Source = VIP address (on the real server) > Destination = Client's IP address > > Whatever is sitting at the edge is unable to match up the reply packet > with the inbound packet, as the IP addresses are different. The reply > packet looks like a new, unrelated connection: the response half of a > connection to a request that hasn't been observed. I think it would > appear as an unsolicited SYN-ACK and be dropped. > > That's my theory, at least. > > Could you test using a proxy style load balancer? That way, the > inbound and reply traffic would all match up nicely. If that works, it > would prove that your setup is sound and working and would narrow down > the problem to being TUN specific. For a test, HAProxy is a great > FLOSS proxy style load balancer. > > Thanks, > Andrew > > -- > Andrew Howe > Loadbalancer.org Ltd. > www.loadbalancer.org > > _______________________________________________ > Please read the documentation before posting - it's available at: > http://www.linuxvirtualserver.org/ > > LinuxVirtualServer.org mailing list - lvs-users@LinuxVirtualServer.org > Send requests to lvs-users-requ...@linuxvirtualserver.org > or go to http://lists.graemef.net/mailman/listinfo/lvs-users > _______________________________________________ Please read the documentation before posting - it's available at: http://www.linuxvirtualserver.org/ LinuxVirtualServer.org mailing list - lvs-users@LinuxVirtualServer.org Send requests to lvs-users-requ...@linuxvirtualserver.org or go to http://lists.graemef.net/mailman/listinfo/lvs-users
