Take the 2-minute tour ×
Server Fault is a question and answer site for professional system and network administrators. It's 100% free, no registration required.

I am setting up a transparent proxy using haproxy, the setup works without the 'source 0.0.0.0 usesrc client' line. When I add that line in, the endpoint is called from the original client's ip address and tcpdump shows that the packets arrive at the target host but they don't seem to be processed or responded to, eventually the request times out.

Broken Tcp Dump Log (Taken from target backend server):
13:36:33.782686 IP 10.3.0.92.56177 > 192.168.0.5.80: Flags [S], seq 2733860398, win 14600, options [mss 1460,sackOK,TS val 2090146 ecr 0,nop,wscale 5], length 0
13:36:34.808390 IP 10.3.0.92.56177 > 192.168.0.5.80: Flags [S], seq 2733860398, win 14600, options [mss 1460,sackOK,TS val 2091146 ecr 0,nop,wscale 5], length 0
13:36:35.600765 IP 10.3.0.92.56185 > 192.168.0.5.80: Flags [S], seq 1518413688, win 14600, options [mss 1460,sackOK,TS val 2091930 ecr 0,nop,wscale 5], length 0
13:36:36.623120 IP 10.3.0.92.56185 > 192.168.0.5.80: Flags [S], seq 1518413688, win 14600, options [mss 1460,sackOK,TS val 2092930 ecr 0,nop,wscale 5], length 0
13:36:36.840211 IP 10.3.0.92.56177 > 192.168.0.5.80: Flags [S], seq 2733860398, win 14600, options [mss 1460,sackOK,TS val 2093146 ecr 0,nop,wscale 5], length 0
13:36:38.665777 IP 10.3.0.92.56185 > 192.168.0.5.80: Flags [S], seq 1518413688, win 14600, options [mss 1460,sackOK,TS val 2094930 ecr 0,nop,wscale 5], length 0
13:36:39.603892 IP 10.3.0.92.56185 > 192.168.0.5.80: Flags [S], seq 1580967374, win 14600, options [mss 1460,sackOK,TS val 2095842 ecr 0,nop,wscale 5], length 0
13:36:40.653243 IP 10.3.0.92.56185 > 192.168.0.5.80: Flags [S], seq 1580967374, win 14600, options [mss 1460,sackOK,TS val 2096842 ecr 0,nop,wscale 5], length 0
13:36:42.742138 IP 10.3.0.92.56185 > 192.168.0.5.80: Flags [S], seq 1580967374, win 14600, options [mss 1460,sackOK,TS val 2098842 ecr 0,nop,wscale 5], length 0
13:36:43.606977 IP 10.3.0.92.56185 > 192.168.0.5.80: Flags [S], seq 1643514971, win 14600, options [mss 1460,sackOK,TS val 2099693 ecr 0,nop,wscale 5], length 0
13:36:44.624129 IP 10.3.0.92.56185 > 192.168.0.5.80: Flags [S], seq 1643514971, win 14600, options [mss 1460,sackOK,TS val 2100693 ecr 0,nop,wscale 5], length 0
13:36:46.653801 IP 10.3.0.92.56185 > 192.168.0.5.80: Flags [S], seq 1643514971, win 14600, options [mss 1460,sackOK,TS val 2102693 ecr 0,nop,wscale 5], length 0
13:36:47.610193 IP 10.3.0.92.56185 > 192.168.0.5.80: Flags [S], seq 1706062128, win 14600, options [mss 1460,sackOK,TS val 2103607 ecr 0,nop,wscale 5], length 0
13:36:48.630226 IP 10.3.0.92.56185 > 192.168.0.5.80: Flags [S], seq 1706062128, win 14600, options [mss 1460,sackOK,TS val 2104607 ecr 0,nop,wscale 5], length 0
13:36:50.665869 IP 10.3.0.92.56185 > 192.168.0.5.80: Flags [S], seq 1706062128, win 14600, options [mss 1460,sackOK,TS val 2106607 ecr 0,nop,wscale 5], length 0



Working Tcp Dump log (Taken from target backend server):
13:37:34.519616 IP 192.168.0.1.55694 > 192.168.0.5.80: Flags [S], seq 926283285, win 14600, options [mss 1460,sackOK,TS val 2149599 ecr 0,nop,wscale 5], length 0
13:37:34.520083 IP 192.168.0.5.80 > 192.168.0.1.55694: Flags [S.], seq 3779931433, ack 926283286, win 14480, options [mss 1460,sackOK,TS val 2354335 ecr 2149599,nop,wscale 6], length 0
13:37:34.520931 IP 192.168.0.1.55694 > 192.168.0.5.80: Flags [.], ack 1, win 457, options [nop,nop,TS val 2149600 ecr 2354335], length 0
13:37:34.520973 IP 192.168.0.1.55694 > 192.168.0.5.80: Flags [P.], seq 1:365, ack 1, win 457, options [nop,nop,TS val 2149600 ecr 2354335], length 364
13:37:34.520985 IP 192.168.0.5.80 > 192.168.0.1.55694: Flags [.], ack 365, win 243, options [nop,nop,TS val 2354336 ecr 2149600], length 0
13:37:34.521188 IP 192.168.0.5.80 > 192.168.0.1.55694: Flags [P.], seq 1:238, ack 365, win 243, options [nop,nop,TS val 2354336 ecr 2149600], length 237
13:37:34.521718 IP 192.168.0.1.55694 > 192.168.0.5.80: Flags [.], ack 238, win 490, options [nop,nop,TS val 2149601 ecr 2354336], length 0
13:37:34.521735 IP 192.168.0.5.80 > 192.168.0.1.55694: Flags [P.], seq 238:850, ack 365, win 243, options [nop,nop,TS val 2354336 ecr 2149601], length 612
13:37:34.522295 IP 192.168.0.1.55694 > 192.168.0.5.80: Flags [.], ack 850, win 528, options [nop,nop,TS val 2149601 ecr 2354336], length 0

Any ideas on why the target system doesn't seem to be seeing these packets? I've stopped iptables on the target host.

UPDATE:

if I set the backend server's gateway to the haproxy then the server responds to the SYN (clearly, since it now knows where to send the response.) but now the haproxy host returns with "host 10.3.0.92 unreachable - admin prohibited, length 68" should the backend host's gateway be set to the haproxy host?

15:31:13.862481 IP 10.3.0.92.63460 > 192.168.0.5.80: Flags [S], seq 2693662872, win 14600, options [mss 1460,sackOK,TS val 6178395 ecr 0,nop,wscale 5], length 0
15:31:13.862548 IP 192.168.0.5.80 > 10.3.0.92.63460: Flags [S.], seq 2196759473, ack 2693662873, win 14480, options [mss 1460,sackOK,TS val 9094716 ecr 6178395,nop,wscale 6], length 0
15:31:13.863366 IP 192.168.0.1 > 192.168.0.5: ICMP host 10.3.0.92 unreachable - admin prohibited, length 68
15:31:14.882199 IP 10.3.0.92.63460 > 192.168.0.5.80: Flags [S], seq 2693662872, win 14600, options [mss 1460,sackOK,TS val 6179395 ecr 0,nop,wscale 5], length 0
15:31:14.882238 IP 192.168.0.5.80 > 10.3.0.92.63460: Flags [S.], seq 2212692439, ack 2693662873, win 14480, options [mss 1460,sackOK,TS val 9095715 ecr 6179395,nop,wscale 6], length 0
15:31:14.882479 IP 192.168.0.1 > 192.168.0.5: ICMP host 10.3.0.92 unreachable - admin prohibited, length 68
...
share|improve this question

1 Answer 1

I believe that I've found the solution, being a developer and not a sys admin, this took a little time to figure out but ultimately, I believe that the issue was that for transparent proxying to work, the proxy needs to also be the target host's default gateway.

That way:

  1. The proxy makes a spoofed call, impersonating the original client
  2. The target host responds to the spoofed call but because the target host isn't on the caller's IP range, it's response goes to it's default gateway
  3. The machine setup as the network's default gateway needs to act as a gateway (obviously) that is, to accept all incoming traffic irrespective of where it's destined and forward it on to it's destination.

So in my case, it looks like I just need to implement step 3 since the proxy host is now complaining about not knowing what to do with the SYN-ACK which the target host responded with.

I'll post an update when I've had time to verify all of that.

share|improve this answer

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.