From eric_li@trend.com.tw Wed Nov 3 16:05:04 2004 From: eric_li@trend.com.tw (eric_li@trend.com.tw) Date: Thu, 4 Nov 2004 00:05:04 +0800 Subject: [tproxy] tproxy on bridge Message-ID: <05D4351F36F7844CAE6F3C64991567450233080D@twexmail01.tw.trendnet.org> This is a multi-part message in MIME format. ------_=_NextPart_001_01C4C1BE.E14B5A8F Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, =0D It seems to me that tproxy works on router (IP layer). Is there any plan to support bridge mode? =0D Or do there exist some similar buddy of tproxy in ebtables ?? =0D Regards, Eric Li TREND MICRO EMAIL NOTICE The information contained in this email and any attachments is confidential= and may be subject to copyright or other intellectual property protection.= If you are not the intended recipient, you are not authorized to use or= disclose this information, and we request that you notify us by reply mail= or telephone and delete the original message from your mail system. ------_=_NextPart_001_01C4C1BE.E14B5A8F Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi,

 

It seems to me that tproxy= works on router (IP layer).

Is there any plan to support bridge= mode?

 

Or do there exist some similar buddy of tproxy in ebtables ??

 

Regards,

Eric Li

TREND MICRO EMAIL= NOTICE
The information contained in this email and any attachments is confidential= and may be subject to copyright or other intellectual property protection.= If you are not the intended recipient, you are not authorized to use or= disclose this information, and we request that you notify us by reply mail= or telephone and delete the original message from your mail system.
------_=_NextPart_001_01C4C1BE.E14B5A8F-- From buytenh@wantstofly.org Wed Nov 3 18:27:18 2004 From: buytenh@wantstofly.org (Lennert Buytenhek) Date: Wed, 3 Nov 2004 19:27:18 +0100 Subject: [tproxy] tproxy on bridge In-Reply-To: <05D4351F36F7844CAE6F3C64991567450233080D@twexmail01.tw.trendnet.org> References: <05D4351F36F7844CAE6F3C64991567450233080D@twexmail01.tw.trendnet.org> Message-ID: <20041103182718.GA7971@xi.wantstofly.org> On Thu, Nov 04, 2004 at 12:05:04AM +0800, eric_li@trend.com.tw wrote: > Hi, Hello, > It seems to me that tproxy works on router (IP layer). > Is there any plan to support bridge mode? It works for me quite nicely in bridge mode. If you can describe what problems you are seeing, perhaps we can fix them. > TREND MICRO EMAIL NOTICE > The information contained in this email and any attachments is > confidential and may be subject to copyright or other intellectual > property protection. If you are not the intended recipient, you are > not authorized to use or disclose this information, and we request > that you notify us by reply mail or telephone and delete the original > message from your mail system. Please get rid of this message when you post to this list. You'll have a very hard time enforcing it in any case. cheers, Lennert From eric_li@trend.com.tw Wed Nov 3 23:49:03 2004 From: eric_li@trend.com.tw (eric_li@trend.com.tw) Date: Thu, 4 Nov 2004 07:49:03 +0800 Subject: [tproxy] tproxy on bridge Message-ID: <05D4351F36F7844CAE6F3C64991567450233080E@twexmail01.tw.trendnet.org> Oh?! I didn't try it in bridge mode. When I saw the README file, the command is=0D iptables -t tproxy -A PREROUTING -j TPROXY --on-port iptables won't see packets in bridge mode, unless you enable CONFIG_BRIDGE_NETFILTER option, right? So, for tproxy to work in bridge, we must enable this option? Regards, Eric Li -----Original Message----- From: Lennert Buytenhek [mailto:buytenh@wantstofly.org]=0D Sent: Thursday, November 04, 2004 2:27 AM To: Eric Li (RD-TW) Cc: tproxy@lists.balabit.hu Subject: Re: [tproxy] tproxy on bridge On Thu, Nov 04, 2004 at 12:05:04AM +0800, eric_li@trend.com.tw wrote: > Hi, Hello, > It seems to me that tproxy works on router (IP layer). > Is there any plan to support bridge mode? It works for me quite nicely in bridge mode. If you can describe what problems you are seeing, perhaps we can fix them. TREND MICRO EMAIL NOTICE The information contained in this email and any attachments is confidential= and may be subject to copyright or other intellectual property protection.= If you are not the intended recipient, you are not authorized to use or= disclose this information, and we request that you notify us by reply mail= or telephone and delete the original message from your mail system. From hokousha2001@yahoo.com Mon Nov 8 02:28:26 2004 From: hokousha2001@yahoo.com (Tim Burress) Date: Sun, 7 Nov 2004 18:28:26 -0800 (PST) Subject: [tproxy] NAT Reservation Message-ID: <20041108022826.81687.qmail@web21121.mail.yahoo.com> Hello! We're using TPROXY 2.0.0 for 2.4.27 and are running into a strange issue which seems related to NAT reservation. As usual, we have a client TCP connection coming in from a given going to a particular . Netfilter rules REDIRECT this to our proxy code, which then uses TPROXY to connect out to using as the apparent source. We use the same operation sequence that appears in the test directory: first bind the socket to a local address, then do a TPROXY ASSIGN assigning to the socket, then TPROXY FLAGS to set ITP_CONNECT|ITP_ONCE, and then the actual connect(). With earlier versions of TPROXY (though I can't guarantee that kernel options haven't changed) this worked fine. Now, though, we see two problems. First, on when we make the call to ASSIGN, we get an error: IP_TPROXY: ip_tproxy_nat_reserve proto 6 foreign 10.0.0.2:32772 peer 0.0.0.0:0 IP_TPROXY: IP_TPROXY_ASSIGN cannot register NAT reservation 0200000a:0480 Apparently the NAT reservation is failing because when the initial TCP connection came in, conntrack set up a record expecting a reply to . The only way I could see to get around this was to set SO_REUSEADDR on the socket before the call to ASSIGN. However the second problem is that, if I do this, I get an error in the FLAGS call: IP_TPROXY: ip_tproxy_nat_reserve proto 6 foreign 10.0.0.2:32775 peer 0.0.0.0:0 IP_TPROXY: IP_TPROXY_FLAGS sr c660bf9c: failed to register NAT reservation I was able to work around these problems by first setting SO_REUSEADDR on the socket before the ASSIGN than clearing it before the FLAGS call, but that doesn't seem ideal. Is this how it's supposed to be done, or do I just have some basic misunderstanding about how TPROXY should be used? I have to admit I'm not clear on the purpose of NAT reservations. Thanks! Tim __________________________________ Do you Yahoo!? Check out the new Yahoo! Front Page. www.yahoo.com From hidden@balabit.hu Mon Nov 8 08:35:04 2004 From: hidden@balabit.hu (KOVACS Krisztian) Date: Mon, 08 Nov 2004 09:35:04 +0100 Subject: [tproxy] Re: TPROXY and NAT In-Reply-To: References: Message-ID: <1099902904.2676.3.camel@nienna.balabit> Hi, 2004-11-06, szo keltezéssel 10:18-kor Sumit Pandya ezt írta: > I'd like to know does the limitation described on following thread has been > overcame after release of 2.0.0 version? > https://lists.balabit.hu/pipermail/tproxy/2003-November/000053.html Basically it's a bad interaction between Netfilter DNAT/MASQUERADE and tproxy. Unfortunately to work around this limitation you have to modify the NAT core code. For more information see https://lists.balabit.hu/pipermail/tproxy/2003-November/000053.html -- Regards, Krisztian KOVACS From hidden@balabit.hu Mon Nov 8 09:12:42 2004 From: hidden@balabit.hu (KOVACS Krisztian) Date: Mon, 08 Nov 2004 10:12:42 +0100 Subject: [tproxy] NAT Reservation In-Reply-To: <20041108022826.81687.qmail@web21121.mail.yahoo.com> References: <20041108022826.81687.qmail@web21121.mail.yahoo.com> Message-ID: <1099905162.2676.44.camel@nienna.balabit> Hi, 2004-11-08, h keltezéssel 03:28-kor Tim Burress ezt írta: > We're using TPROXY 2.0.0 for 2.4.27 and are running > into a strange issue which seems related to NAT > reservation. As usual, we have a client TCP connection > coming in from a given going to a > particular . Netfilter rules REDIRECT > this to our proxy code, which then uses TPROXY to > connect out to using as > the apparent source. > > We use the same operation sequence that appears in the > test directory: first bind the socket to a local > address, then do a TPROXY ASSIGN assigning > to the socket, then TPROXY FLAGS to set > ITP_CONNECT|ITP_ONCE, and then the actual connect(). > > With earlier versions of TPROXY (though I can't > guarantee that kernel options haven't changed) this > worked fine. Now, though, we see two problems. First, > on when we make the call to ASSIGN, we get an error: > > IP_TPROXY: ip_tproxy_nat_reserve proto 6 foreign > 10.0.0.2:32772 peer 0.0.0.0:0 > IP_TPROXY: IP_TPROXY_ASSIGN cannot register NAT > reservation 0200000a:0480 > > Apparently the NAT reservation is failing because when > the initial TCP connection came in, conntrack set up a > record expecting a reply to . The only > way I could see to get around this was to set > SO_REUSEADDR on the socket before the call to ASSIGN. > > However the second problem is that, if I do this, I > get an error in the FLAGS call: > > IP_TPROXY: ip_tproxy_nat_reserve proto 6 foreign > 10.0.0.2:32775 peer 0.0.0.0:0 > IP_TPROXY: IP_TPROXY_FLAGS sr c660bf9c: failed to > register NAT reservation > > I was able to work around these problems by first > setting SO_REUSEADDR on the socket before the ASSIGN > than clearing it before the FLAGS call, but that > doesn't seem ideal. Is this how it's supposed to be > done, or do I just have some basic misunderstanding > about how TPROXY should be used? I have to admit I'm > not clear on the purpose of NAT reservations. Before using TPROXY_FLAGS you should specify the other endpoint of the new connection using TPROXY_CONNECT. Try something like this (augmented foreign-tcp-connect.c, completely untested): 54 /* assign foreign address */ 55 itp.op = TPROXY_ASSIGN; 56 inet_aton(FOREIGN_IP, (struct in_addr *) &itp.v.addr.faddr); 57 itp.v.addr.fport = htons(2000); 58 59 if (setsockopt(sock, SOL_IP, IP_TPROXY, &itp, sizeof(itp)) == -1) 60 { 61 perror("setsockopt(SOL_IP, IP_TPROXY, TPROXY_ASSIGN)"); 62 return -1; 63 } 64 65 /* specify peer endpoint: the same address we will pass to connect() */ 66 itp.op = TPROXY_CONNECT; 67 inet_aton(DEST_IP, (struct in_addr *) &itp.v.addr.faddr); 68 itp.v.addr.fport = htons(80); 69 if (setsockopt(sock, SOL_IP, IP_TPROXY, &itp, sizeof(itp)) == -1) 70 { 71 perror("setsockopt(SOL_IP, IP_TPROXY, TPROXY_CONNECT)"); 72 return -1; 73 } 74 75 /* set connect flag on socket */ 76 itp.op = TPROXY_FLAGS; 77 itp.v.flags = ITP_CONNECT | ITP_ONCE; 78 if (setsockopt(sock, SOL_IP, IP_TPROXY, &itp, sizeof(itp)) == -1) 79 { 80 perror("setsockopt(SOL_IP, IP_TPROXY, TPROXY_FLAGS)"); 81 return -1; 82 } 83 84 /* connect */ 85 inet_aton(DEST_IP, &sin.sin_addr); 86 sin.sin_port = htons(80); 87 if (connect(sock, (struct sockaddr *) &sin, sizeof(sin)) == -1) 88 { 89 perror("connect"); 90 return -1; 91 } -- Regards, Krisztian KOVACS From hokousha2001@yahoo.com Wed Nov 10 10:55:31 2004 From: hokousha2001@yahoo.com (Tim Burress) Date: Wed, 10 Nov 2004 02:55:31 -0800 (PST) Subject: [tproxy] NAT Reservation In-Reply-To: <1099905162.2676.44.camel@nienna.balabit> Message-ID: <20041110105531.22568.qmail@web21127.mail.yahoo.com> Hello! --- KOVACS Krisztian wrote: > Before using TPROXY_FLAGS you should specify the > other endpoint of the > new connection using TPROXY_CONNECT. This works up to a point, but we run into trouble if the destination address is subject to a DNAT rule. In that case, if we use TPROXY_CONNECT to specify the remote endpoint, we kind of shoot ourselves in the foot because by the time TPROXY sees the packet in POSTROUTING, the packet's destination address will have changed. The workaround of playing games with SO_REUSEADDR seems to do OK in this situation, but it's ugly and I'm not sure what the side effects might be. Tim __________________________________ Do you Yahoo!? Check out the new Yahoo! Front Page. www.yahoo.com From javier@magma.ca Wed Nov 24 22:53:17 2004 From: javier@magma.ca (Javier Govea) Date: Wed, 24 Nov 2004 17:53:17 -0500 (EST) Subject: [tproxy] ICMP and tproxy Message-ID: <200411242253.iAOMrHAg027373@webmail1.magma.ca> Hi, I am writing an proxy for different appliacations. So, far it's working with UDP and TCP. All packets arriving at my proxy machine are redirected, with iptables, to the the proxy server, which extracts the final destination of each packet. For the UDP case I am using a tproxy rule to forward all traffic to the proxy server. The proxy server is using something similar to redirect-udp-recv.c to exctract final destinations. Now, I need my proxy to support pings and thus ICMP packets. Can use the tproxy to forward ICMP packets to my proxy??? and to extract final destination similar to redirect-udp-recv.c??? If this is not possible, is there any alternative? Thanks in advance Xavier From bazsi@balabit.hu Thu Nov 25 08:45:25 2004 From: bazsi@balabit.hu (Balazs Scheidler) Date: Thu, 25 Nov 2004 09:45:25 +0100 Subject: [tproxy] ICMP and tproxy In-Reply-To: <200411242253.iAOMrHAg027373@webmail1.magma.ca> References: <200411242253.iAOMrHAg027373@webmail1.magma.ca> Message-ID: <1101372325.4414.14.camel@bzorp.balabit> ICMP is not currently supported by TProxy directly. However you can use raw sockets to achieve the same result. On Wed, 2004-11-24 at 23:53, Javier Govea wrote: > Hi, > > I am writing an proxy for different appliacations. So, far it's working with UDP and TCP. > All packets arriving at my proxy machine are redirected, with iptables, to the the proxy > server, which extracts the final destination of each packet. For the UDP case I am using a > tproxy rule to forward all traffic to the proxy server. The proxy server is using > something similar to redirect-udp-recv.c to exctract final destinations. > > Now, I need my proxy to support pings and thus ICMP packets. Can use the tproxy to forward > ICMP packets to my proxy??? and to extract final destination similar to > redirect-udp-recv.c??? If this is not possible, is there any alternative? > > Thanks in advance > Xavier > > > _______________________________________________ > tproxy mailing list > tproxy@lists.balabit.hu > https://lists.balabit.hu/mailman/listinfo/tproxy -- Bazsi From javier@magma.ca Thu Nov 25 22:56:51 2004 From: javier@magma.ca (Javier Govea) Date: Thu, 25 Nov 2004 17:56:51 -0500 (EST) Subject: [tproxy] ICMP and tproxy Message-ID: <200411252256.iAPMupvh021290@webmail1.magma.ca> Hi, Thank you for your prompt response. I was planning to use raw sockets from the begining. But I got a little problem. This is my setup: Client ----------- Proxy --------- Server If I run a raw socket server in my Proxy box and I ping the Proxy from my Client, then my raw socket server can get all the pings. But if I ping the Server from my Client, then my my raw server in the Proxy does not capture anything, because (I'm guessing) it is not inteded for the Proxy box. So, somehow I need to pass that ping to my raw server. I cannot use tproxy and the iptables REDIRECT target because REDIRECT requires a port number, and there are no ports for ICMP packets. So, is there any alternative solution? Am I missing something? Below is the code I am using for my raw server. Thanks in advance. Xavier int main() { int sockfd; if ((sockfd = socket(AF_INET, SOCK_RAW, IPPROTO_ICMP)) < 0) { perror("Socket:"); return -1; } struct sockaddr_in srcaddr; socklen_t srclen = sizeof(struct sockaddr_in); unsigned char buffer [2000]; int len = 2000; int bytes; struct icmphdr *icmphdr; while(1) { printf ("Waiting for pings...\n"); if ( (bytes = recvfrom(sockfd, buffer, len, 0, (struct sockaddr *)&srcaddr, &srclen)) < 0) perror("rcvfrom"); else { icmphdr = (struct icmphdr *)(buffer + sizeof(struct iphdr)); printf ("Received %d bytes from %s:%d ICMP header: type %d code %d seq %d id %d\n", bytes, inet_ntoa(srcaddr.sin_addr), ntohs(srcaddr.sin_port), icmphdr->type, icmphdr->code, ntohs(icmphdr->un.echo.sequence), ntohs(icmphdr->un.echo.id) ); } } return 1; } ICMP is not currently supported by TProxy directly. However you can use raw sockets to achieve the same result. On Wed, 2004-11-24 at 23:53, Javier Govea wrote: > Hi, > > I am writing an proxy for different appliacations. So, far it's working with UDP and TCP. > All packets arriving at my proxy machine are redirected, with iptables, to the the proxy > server, which extracts the final destination of each packet. For the UDP case I am using a > tproxy rule to forward all traffic to the proxy server. The proxy server is using > something similar to redirect-udp-recv.c to exctract final destinations. > > Now, I need my proxy to support pings and thus ICMP packets. Can use the tproxy to forward > ICMP packets to my proxy??? and to extract final destination similar to > redirect-udp-recv.c??? If this is not possible, is there any alternative? > > Thanks in advance > Xavier > > > _______________________________________________ > tproxy mailing list > tproxy@lists.balabit.hu > https://lists.balabit.hu/mailman/listinfo/tproxy -- Bazsi