- tproxy - lists.balabit.hu

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

Bad Interaction between NAT and TPROXY
by Tim Burress 29 Sep '04

29 Sep '04

Hello! We're seeing a problem when we combine NAT and TPROXY 1.2.1 on a firewall system with application-layer proxies in the 2.4.26 kernel. Say the firewall system has two interfaces, public (202.20.5.1) and private (10.0.0.1). There is an SMTP server (10.0.0.2) on the private network, and we have DNAT rules configured to map 202.20.5.1 ---> 10.0.0.2 So then, in practice, the SMTP proxy on the firewall receives a redirected SMTP connection from a client (90.1.1.1) on the net. It then does its application stuff, and sets up a connection to the server by: (1) Binding a socket to a local address (2) Setting up a TPROXY assignment from the local address to 90.1.1.1 (3) Connect out to the server using the destination address recovered by getsockopt(ORIGINAL_DST) on the original incoming socket This all works fine when there is no NAT (and the private addresses are eliminated). In that case, what the server sees is an incoming connection from 90.1.1.1. But with NAT in the picture, what the server sees is an incoming connection from 10.0.0.1. Working through the kernel code, it appears that when CONFIG_IP_NF_NAT_LOCAL is enabled, there is a call to do_extra_mangle() in ip_nat_core.c that is forcing the source address of outgoing packets to be the preferred source from the routing tables in the LOCAL_OUT hook, so by the time the packet gets to POSTROUTING, the outbound packet no longer matches the TPROXY rule that we set up, so the source address goes out as-is. Looking for a general solution, all I can think of at the moment is to patch ip_nat_core.c so that the call to do_extra_mangle.c is skipped if connection has been assigned by TPROXY, on the theory that the code setting up the TPROXY assignment knows what it wants the final source or destination to be, and that this should take priority over the extra mangling done by NAT. Perhaps testing for IPS_TPROXY before the call to do_extra_mangle()? If that would work (the code is still a jungle to me), it seems like this would solve the problem and still be relatively harmless, but I'm not sure. Actually I'm not sure why the NAT code rewrites the source address of a DNAT packet anyway (or the destination address of an SNAT packet), so it makes me nervous. What we do now as a workaround in simple networks is manually force the proxy to bind the local socket to 10.0.0.1 before the TPROXY assignment. It's ugly, but it works, since it anticipates how the kernel will mangle the packets. However it's obviously not a good general solution, and would fail in complex networks where routing to the destination is dynamic. What's the best way to deal with this? Thanks! Tim _______________________________ Do you Yahoo!? Win 1 of 4,000 free domain names from Yahoo! Enter now. http://promotions.yahoo.com/goldrush

2 4

tproxy setup resulting in martian logging
by Igmar Palsenberg 02 Aug '04

02 Aug '04

Hi, I've got a 2.4.26 kernel with grsec + openswan + tproxy support. I want to redirect specific destinations to a proxy on the local machine. An example : redirect all trafic to port 12345 to the proxy on 127.0.0.1:12345. The iptables rule : iptables -t tproxy -A PREROUTING -p tcp -d 0.0.0.0/0 --dport 12345 -j TPROXY --on-port 12345 --on-ip 127.0.0.1 Doing a telnet to some IP on port 12345 results in : Aug 2 21:43:28 fw kernel: martian destination 127.0.0.1 from 10.1.1.52, dev eth1 where 10.1.1.52 is the machine initiating the telnet, 10.1.1.1 is the machine where the packet enters the IP stack on eth1. The relevant function in this case seems to be ip_route_input_slow() in net/ipv4/route.c. The behaviour is logical, but prevents tproxy support from working in this case. Any suggestions ??? Regards, Igmar

1 0

FW: tproxy getsockopt call
by Andrew Ivins 07 Jul '04

07 Jul '04

Hi, Bit of a low level question, again probably one for Krisztian. One of our developers is trying to ascertain what the original peer addresses are on a tproxy socket. In the code snippet below, he prints out the original source and destination addresses. However they are always zero. Does anybody know the correct way of doing this? We are still using cttproxy-2.4.25-1.9.3. > Here's the code sample > > struct in_origaddrs orig; > ... > ... > if ( getsockopt(fd, SOL_IP, IP_ORIGADDRS, &orig, &orig_len) ) { > debug(5, 1) ("commConnectStart: Couldn't get original > address for fd\n"); > } else { > debug(5, 1) ("commConnectStart: FD = %d\n", fd); > debug(5, 1) ("commConnectStart: Original source address > is %s\n", > inet_ntoa(orig.ioa_srcaddr)); > debug(5, 1) ("commConnectStart: Original destination > address is %s\n", > inet_ntoa(orig.ioa_dstaddr)); > } > > Regards, Andrew Ivins System Administrator Swiftel Communications (08) 9480 1233

2 1

TProxy version 1.2.1 released
by KOVACS Krisztian 18 Jun '04

18 Jun '04

Hi, After more than six months, a new stable version of TProxy has been released today. In the last few months a couple of problems were found in TProxy 1.2.0, some of them requiring substantial changes to the code. This is why the test version 1.2.0.1 was released earlier this month. After doing some testing, we think that it is ready for production use. The most important changes in the new release: * introduction of shared sockrefs for mark-only entries, this fixes the "clashing entries" problem which occured in special cases of operation * new method for maintaining the per-sockref related connections list, now connections are added only at confirmation-time * fix order of registration of hooks and the 'tproxy' table, when the iptable_tproxy module was loaded on high traffic sites, it could oops None of these changes cause binary incompatibility, the userspace interface is completely the same as that of 1.2.0. Tarballs for Linux version 2.4.25 and 2.4.26 are available on our website: http://www.balabit.com/downloads/tproxy/linux-2.4/ MD5 checksums of the files: ea9cf2c2efe77f658f512d71e3ffc481 cttproxy-2.4.25-1.2.1.tar.gz d8977620a1903c04d2f297a90fcf3709 cttproxy-2.4.26-1.2.1.tar.gz -- Regards, Krisztian KOVACS

1 0

Development version 1.9.6 released
by KOVACS Krisztian 04 Jun '04

04 Jun '04

Hi, A new version of the development branch of TProxy has been released. The most important new internal feature is the introduction of shared sockrefs, and of course quite a few smaller fixes are included as well. This version has been prepared for Linux 2.4.25 and Linux 2.6.6, both with Jozsef Kadlecsik's TCP-window-tracking patch applied. (It's availble in the Netfilter project's Patch-o-Matic-NG.) Without this patch, 04-nat_delete won't apply at all, and all the other patches may cause (trivial) rejects when patching. The release is available on our site, and will shortly be available in the CVS version Patch-o-Matic-NG: http://www.balabit.com/downloads/tproxy/linux-2.4/devel/ MD5: 577224ea8c0a6f3ee191509ba77f6fd7 cttproxy-2.4.25-1.9.6.tar.gz MD5: 6e4993720a3eaaecdf1fe42bf6e8f147 cttproxy-2.6.6-1.9.6.tar.gz -- Regards, Krisztian KOVACS

1 0