October 2004 - tproxy - lists.balabit.hu

Interaction with IPVS
by Tim Burress 19 Oct '04

19 Oct '04

Hello! We're running into another potential interaction, this time between tproxy and IPVS http://www.linuxvirtualserver.org on Linux 2.4.27. What we see with TPPROXY 2.0, and going at least as far back as 1.9.6, is that incoming connections that go through IPVS for load balancing are properly mapped to a real server, but when the reply packets come back from the real server, they aren't recognized. Conntrack considers the connection [UNREPLIED] even though tcpdump shows that the reply packets are arriving with the expected source and destination address/ports. It seems like the reply packets are being dropped. The only evidence suggesting that TPROXY is involved at this point is the observation that the problem doesn't appear when we use TPROXY 1.2. One other data point is that, when we use TPROXY 2.0, the problem appears even when the module is not loaded, so it seems to be a side effect of patches to other modules. I realize this is vague, and we're trying to track it down, but I thought I would post and just see if anyone else has observed similar behavior, or if there are any ideas for locating the source of the problem. Thanks! Tim _______________________________ Do you Yahoo!? Declare Yourself - Register online to vote today! http://vote.yahoo.com

2 4

Re: [tproxy] UDP tproxy
by Javier Govea 16 Oct '04

16 Oct '04

Thank you very much for your comments. I did all modifications you mentioned and I checked redirect-udp-recv.c and now my C program works without any problem. I have only one last question, it is just curiosity. redirect-udp-recv.c has the following lines of code. /* check tproxy version */ itp.op = TPROXY_VERSION; itp.v.version = 0x02000000; if (setsockopt(sock, SOL_IP, IP_TPROXY, &itp, sizeof(itp)) == -1) { perror("setsockopt(SOL_IP, IP_TPROXY, TPROXY_VERSION)"); return -1; } Is this part optional? What happen if I set the wrong version? Does it mean that my program works only a specific tproxy version? Thanks a lot again Xavier On Oct 15, KOVACS Krisztian <hidden(a)balabit.hu> wrote: > > > Hi, > > 2004-10-14, cs keltez�ssel 23:45-kor Javier Govea ezt �rta: > > I've been googling for some information about using tproxy for UDP traffic but I am still > > a bit confiused. I hope you guys can help me out. > > > > I want to intercept, at the application layer with a C written program, all UDP traffic, > > and then obtain the final destionation IP address and port. > > > > So, please correct me if I am wrong, I need two rules: > > > > iptables -t nat -A PREROUTING -j DNAT --to-dest 192.168.1.10 > > iptables -t tproxy -A PREROUTING -j TPROXY --on-port 1025 > > You don't need the DNAT rule, only the TPROXY one. You can also > specify a destination IP to TPROXY with --on-ip, if you omit that > argument it will use the address of the interface the packet came in. > > > /* QUESTION 1: > > * Do I need to use getsockopt or setsockopt in here??? > > * If so, what exactly should I pass as paramenters to getsockopt or setsockopt > > * Krisztian Kovacs, in a message posted in this list on 07 Jul 2004, mentions > > * that I need to use getsockopt, but I'm not sure about the > > * paramenters I need to pass, can somebody please clarify this point? > > */ > > Yes, you have to set the RECVORIGADDRS socket option with setsockopt() > in order to receive the original address with recvmsg(). > > > /* QUESTION 2: > > * The same message posted by Krisztian Kovacs mentions that I need to use > > * recvmsg and that the original destination IP address and port is the > > * acilliary data. Is the following code correct??? Is that how I suppose to > > * extract the payload, original destination IP address and port > > * from the ancilliary data? > > */ > > You got the msg setup right, but do not process the received msg > appropriately. Read below. > > > /* QUESTION 3: > > * Is the payload suppose to be in cdata? > > */ > > void *cdata = CMSG_DATA(cmsg); > > No, it's in msgh.msg_iov.iov_base (buffer in your case). > > > > > /* QUESTION 4: > > * The original destination IP address and port are in msgh.msg_name??? > > */ > > sockaddr_in *originalDst = (sockaddr_in *)(msgh.msg_name); > > No, it's in CMSG_DATA(cmsg). > > > /* Original destination IP address in originalDst->sin_addr.s_addr and > > * original destination port in originalDst->sin_port > > * Does any of this make any sense??? > > */ > > Yes. But please take a look at the example code, redirect-udp-recv.c > is _exactly_ you're looking for. > > -- > Regards, > Krisztian KOVACS > >

2 1

UDP tproxy
by Javier Govea 15 Oct '04

15 Oct '04

Hi, I've been googling for some information about using tproxy for UDP traffic but I am still a bit confiused. I hope you guys can help me out. I want to intercept, at the application layer with a C written program, all UDP traffic, and then obtain the final destionation IP address and port. So, please correct me if I am wrong, I need two rules: iptables -t nat -A PREROUTING -j DNAT --to-dest 192.168.1.10 iptables -t tproxy -A PREROUTING -j TPROXY --on-port 1025 These two rules suppose to redirect all UDP traffic to my box (192.168.1.10) to my C program listening to port 1025, am i right? Now, my C program needs to obtain the payload, original destination IP address and port is below. However I receive no ancilliary data, in my program msgh.msg_controllen is always equal to zero. Any suggestions?? All ideas are very welcomed. Thank you Xavier PS. Here is the code: int main() { int fd; struct sockaddr_in myAddr; struct sockaddr_in originalAddr; struct msghdr msgh; struct iovec v; unsigned char acilliarydatabuff[1000]; unsigned char buffer[MAXBUFFSIZE]; int bytes; if ((fd = socket(AF_INET, SOCK_DGRAM, 0)) == -1) return 0; memset((char *)&myAddr, 0x0, sizeof(struct sockaddr_in)); myAddr.sin_family = AF_INET; myAddr.sin_port = htons(1025); myAddr.sin_addr.s_addr = htonl(INADDR_ANY); if (bind(fd, (struct sockaddr *)&myAddr, sizeof(struct sockaddr_in)) == -1) return 0; /* QUESTION 1: * Do I need to use getsockopt or setsockopt in here??? * If so, what exactly should I pass as paramenters to getsockopt or setsockopt * Krisztian Kovacs, in a message posted in this list on 07 Jul 2004, mentions * that I need to use getsockopt, but I'm not sure about the * paramenters I need to pass, can somebody please clarify this point? */ for(;;) { /* QUESTION 2: * The same message posted by Krisztian Kovacs mentions that I need to use * recvmsg and that the original destination IP address and port is the * acilliary data. Is the following code correct??? Is that how I suppose to * extract the payload, original destination IP address and port * from the ancilliary data? */ memset((char *)&originalAddr, 0x0, sizeof(struct sockaddr_in)); memset(&msgh, 0, sizeof(msgh)); msgh.msg_name = &originalAddr; msgh.msg_namelen = sizeof(struct sockaddr_in); v.iov_base = buffer; v.iov_len = MAXBUFFSIZE; msgh.msg_iov = &v; msgh.msg_iovlen = 1; msgh.msg_control = acilliarydatabuff; msgh.msg_controllen = 1000; if ( (bytes = recvmsg(fd, &msgh, 0)) == -1 ) continue; // Get ancilliary data struct cmsghdr *cmsg; if (msgh.msg_controllen > 0) for (cmsg = CMSG_FIRSTHDR(&msgh); cmsg!=NULL; cmsg = CMSG_NXTHDR(&msgh,cmsg)) { /* QUESTION 3: * Is the payload suppose to be in cdata? */ void *cdata = CMSG_DATA(cmsg); /* QUESTION 4: * The original destination IP address and port are in msgh.msg_name??? */ sockaddr_in *originalDst = (sockaddr_in *)(msgh.msg_name); /* Original destination IP address in originalDst->sin_addr.s_addr and * original destination port in originalDst->sin_port * Does any of this make any sense??? */ } } }

2 1

[ANN] tproxy binary packages for Red Hat 7.3, 9, Fedora Core 2
by Lennert Buytenhek 11 Oct '04

11 Oct '04

Hi! I've created some RPMS of tproxy-patched kernels for various Red Hat flavours, and published them at: http://tproxy.wantstofly.org/ There are kernels for: - Red Hat 7.3 with tproxy 1.2.1 - Red Hat 7.3 with tproxy 2.0.0 - Red Hat 9 with tproxy 1.2.1 - Red Hat 9 with tproxy 2.0.0 - Fedora Core 2 with tproxy 2.0.0 I've only built updated iptables packages for FC2 so far. Please let me know if you experience any problems with these. cheers, Lennert

2 1

TProxy version 2.0.0 released
by KOVACS Krisztian 11 Oct '04

11 Oct '04

Hi, The first version of the new TProxy stable branch, TProxy 2.0.0 has been released. There were no changes affecting functionality, only some cleanups and updates necessary for newer Linux 2.6 kernels. This version is _not_ compatible with TProxy 1.2.x, you have to make a some trivial changes to your source code and recompile the application. It is important to note, that our GPL-ed Zorp proxy does not support TProxy 2.0 yet. Important new features of the TProxy 2.0 branch: * TProxy version number detection * Through NAT reservations, assignment operations are more safe, if the setsockopt() operation succeeds, the NAT operation will succeed as well * Improved wildcart port handling, it is possible to force port allocation for an assigned socket with unspecified port number Patchsets are available for Linux 2.4.27 and 2.6.8.1. The release contains Jozsef Kadlecsik's TCP window tracking patch, but that part is completely optional, all other patches except for the 04-nat_delete.diff can be applied with or without window tracking. If everything goes well, the release will be available shortly in Netfilter Patch-o-Matic-NG as well. http://www.balabit.com/downloads/tproxy/linux-2.4/ http://www.balabit.com/downloads/tproxy/linux-2.6/ MD5: bb8b61abc2a361acec7ed2d8c30f25f7 cttproxy-2.4.27-2.0.0.tar.gz MD5: 4147727427cdf10d4aa96033b363dedc cttproxy-2.6.8.1-2.0.0.tar.gz -- Regards, Krisztian KOVACS

2 2

TPROXY / Zorp on READHAT 9
by TEJAS VORA 06 Oct '04

06 Oct '04

Hi, I have already sent a mail to Info Team but I havent got any response yet. We are developing a gateway which provides the functionality to improve TCP communication in Wireless network through a kernel code change. Now we are running our gateway in full bridge mode and to push TCP traffice up in the stack - we want to use the proxy on the gateway machine - so that all interested traffice will be pushed up in the stack till TCP layer. For this reason, we want to try Zorp and TPROXY on out machine. For that reason right now I am trying Zorp GPL / TPROXY on our machine. We want to support - source IP NOT Changing (becuase of IP authentication) - We want to support more than 1000 sessions at a same time - so performance is a critical issue - While sending FTP data back to client - source port should remain 20 (ftp-data) Out machine config is: READHAT 9 - kernel 2.4.20-8 - clean and full installation I have downloaded the latest kernel pacth for TPROXY from your site. (I couldnt find one for 2.4.20-8) While I am trying to patch kernel source - some of the file are missing - like - ip_nat_amanda.c - whether it is okay? While trying to build modules - it is not working. Also, I patch iptables source - and trying to work with it - it compile fine - but when I try to use -j TPROXY - it says - libipt_TPROXY.so module not found. Now here I am really stranded and not able to do anything - I guess mainly becuase of version conflict - or some other reason. So please help me on this as soon as possible - so that we can test the product and decide on buying professional product. Looking for response ASAP. Thanks, Tejas

2 1