[tproxy] NAT Reservation

[KOVACS Krisztian]

  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 <saddr,sport> going to a
> particular <daddr,dport>. Netfilter rules REDIRECT
> this to our proxy code, which then uses TPROXY to
> connect out to <daddr,dport> using <saddr,sport> 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
> <saddr,sport> 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 <saddr,sport>. 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