On 18:22:37 Oct 25, uday wrote: > Hi Guys, > > I'm trying out relayd here and first of all, filicitation to PYR and > the community for their work on this piece of software. This is my > first time install and while trying it out, I came on to an issue, I > keep on getting "tcp_write: connect timed out" when relayd checks the > hosts table. I searched the entire net for a solution and the only > solution I found is that a good timeout could solve the issue (rather > than a patch that is wrong said by the man himself PYR), I just ran > out of luck I tried in every possible way to change the config of this > it's just not working, on the webserver side I'm not even seing an > attempt to connect, this is weird for me. I know I'm doing something > wrong here but I don't see it, I greatly appreciate if anyone > encountered this problem to share a bit of info with me. > > This is the message I'm getting when I try to connect to the > loadbalancer on port 80: > > "relay httpproxy, session 1 (1 active), 0, 192.168.4.22 -> :80, session > failed" >
It could well be a simple networking/routing issue. I have seen this whilst testing relayd for the first time. Although it is taken for granted that the logical network topology matches the routing tables we often do not abide by this rule. For instance can you ensure that you can connect to the web server from the redirector(the machine running relayd) by using netcat? Run this on the web server. $ nc -l 1234 and from the relayd machine try $ nc 192.168.4.78 1234 I would also check if the webserver is healthy and running fine though I am sure you would have done that sanity check. If the routing tables are not in order you have got something wrong in your setup and that is the first thing to fix. For instance have you ensured that the web server and the clients are in separate networks connected/routed by the relayd machine? There are certain unwritten ground rules to be followed for rdr to work. For instance if your reverse path does not match the forward path between the client and the server, then rdr will fail and the TCP handshake will not go through. Basically rdr should get a chance to see the packets in both directions to function properly. Kindly ensure that. Thanks. -Girish
