<html>
  <head>
    <meta content="text/html; charset=ISO-8859-1"
      http-equiv="Content-Type">
  </head>
  <body bgcolor="#FFFFFF" text="#000000">
    <div class="moz-cite-prefix">El 03/08/13 21:39, Michal Trojnara
      escribió:<br>
    </div>
    <blockquote cite="mid:51FD5C61.9050504@mirt.net" type="cite">
      <pre wrap="">On 2013-08-03 20:24, Ruben Cardenal wrote:
</pre>
      <blockquote type="cite">
        <pre wrap="">And did the iptables part:

iptables -t mangle -N DIVERT
iptables -t mangle -A PREROUTING -p tcp -m socket -j DIVERT
iptables -t mangle -A DIVERT -j MARK --set-mark 1
iptables -t mangle -A DIVERT -j ACCEPT
ip rule add fwmark 1 lookup 100
ip route add local 0.0.0.0/0 dev lo table 100

Debugging the whole thing, it can be seen that stunnel tries to connect:

[pid 16823] connect(9, {sa_family=AF_INET, sin_port=htons(1357),
sin_addr=inet_addr("195.78.X.X")}, 16) = -1 EINPROGRESS (Operation now
in progress)

BUT the service running in 1357 does this:

# tcpdump -i eth1 -n port 1357
tcpdump: verbose output suppressed, use -v or -vv for full protocol
decode
listening on eth1, link-type EN10MB (Ethernet), capture size 65535 bytes
19:52:52.586773 IP 195.78.X.X.1357 > MY_HOME_ADDRESS.34853: Flags
[S.], seq 2655966098, ack 546202865, win 5840, options [mss
1460,nop,nop,sackOK], length 0
</pre>
      </blockquote>
      <pre wrap="">
It looks like you configured your server and stunnel on the same host. 
As the result returning packets won't ever hit the PREROUTING chain of
the mangle table, thus stunnel won't receive them.
<a class="moz-txt-link-freetext" href="http://www.iptables.info/en/structure-of-iptables.html">http://www.iptables.info/en/structure-of-iptables.html</a>

I'm sure the documentation I wrote could be better...

Mike

</pre>
    </blockquote>
    <br>
    Hi Mike,<br>
    <br>
    I've given a try to what you say. I've moved stunnel to another box,
    while leaving the service where it was. Removed iptables stuff from
    the service's box, and leaving there just the backend service. In
    the new box, compiled the same last stunnel version and used the
    same configuration, changing only the connect part, applying
    iptables, etc. And this is what is seen (please note both servers
    are in perfect ntp sync):<br>
    <br>
    stunnel log, same thing, only changing connect IP:<br>
    <br>
    2013.08.03 23:23:09 LOG6[26792:139762318628608]: connect_blocking:
    connecting SERVICE:1357<br>
    2013.08.03 23:23:09 LOG7[26792:139762318628608]: connect_blocking:
    s_poll_wait SERVICE:1357: waiting 10 seconds<br>
    2013.08.03 23:23:18 LOG3[26792:139762318628608]: connect_blocking:
    connect SERVICE:1357: Connection timed out (110)<br>
    2013.08.03 23:23:18 LOG5[26792:139762318628608]: Connection reset: 0
    byte(s) sent to SSL, 0 byte(s) sent to socket<br>
    <br>
    stunnel process:<br>
    <br>
    [pid   569] 23:23:09 bind(9, {sa_family=AF_INET,
    sin_port=htons(50573), sin_addr=inet_addr("HOME")}, 16) = 0<br>
    [pid   569] 23:23:09 sendto(6, "<30>Aug  3 23:23:49 stunnel:
    LOG6[534:140271099127552]: local_bind succeeded on the original
    port", 97, MSG_NOSIGNAL, NULL, 0) = 97<br>
    <br>
    [pid   569] 23:23:09 write(8, "2013.08.03 23:23:09
    LOG6[534:140271099127552]: connect_blocking: connecting
    SERVICE:1357\n", 96) = 96<br>
    [pid   569] 23:23:09 connect(9, {sa_family=AF_INET,
    sin_port=htons(1357), sin_addr=inet_addr("SERVICE")}, 16) = -1
    EINPROGRESS (Operation now in progress)<br>
    <br>
    <br>
    tcpdump in service's box:<br>
    <br>
    23:23:09.015940 IP MYHOME.50573 > SERVICE.1357: Flags [S], seq
    3062456285, win 5840, options [mss 1460,nop,nop,sackOK], length 0<br>
    23:23:09.015969 IP SERVICE.1357 > MYHOME.50573: Flags [S.], seq
    3120433945, ack 3062456286, win 5840, options [mss
    1460,nop,nop,sackOK], length 0<br>
    23:23:12.013679 IP MYHOME.50573 > SERVICE.1357: Flags [S], seq
    3062456285, win 5840, options [mss 1460,nop,nop,sackOK], length 0<br>
    23:23:12.013701 IP SERVICE.1357 > MYHOME.50573: Flags [S.], seq
    3120433945, ack 3062456286, win 5840, options [mss
    1460,nop,nop,sackOK], length 0<br>
    23:23:12.813537 IP SERVICE.1357 > MYHOME.50573: Flags [S.], seq
    3120433945, ack 3062456286, win 5840, options [mss
    1460,nop,nop,sackOK], length 0<br>
    23:23:18.817538 IP SERVICE.1357 > MYHOME.50573: Flags [S.], seq
    3120433945, ack 3062456286, win 5840, options [mss
    1460,nop,nop,sackOK], length 0<br>
    <br>
    <br>
    tcpdump in stunnel's box:<br>
    <br>
    23:23:08.343486 IP MYHOME.50573 > STUNNEL.6697: Flags [S], seq
    1065154599, win 14600, options [mss 1452,sackOK,TS val 121378180 ecr
    0,nop,wscale 7], length 0<br>
    23:23:08.343547 IP STUNNEL.6697 > MYHOME.50573: Flags [S.], seq
    40478691, ack 1065154600, win 5840, options [mss
    1460,nop,nop,sackOK], length 0<br>
    23:23:08.363058 IP MYHOME.50573 > STUNNEL.6697: Flags [.], ack 1,
    win 14600, length 0<br>
    23:23:08.678217 IP MYHOME.50573 > STUNNEL.6697: Flags [P.], seq
    1:151, ack 1, win 14600, length 150<br>
    23:23:08.678271 IP STUNNEL.6697 > MYHOME.50573: Flags [.], ack
    151, win 6432, length 0<br>
    23:23:08.682553 IP STUNNEL.6697 > MYHOME.50573: Flags [.], seq
    1:1453, ack 151, win 6432, length 1452<br>
    23:23:08.682566 IP STUNNEL.6697 > MYHOME.50573: Flags [P.], seq
    1453:1809, ack 151, win 6432, length 356<br>
    23:23:08.697844 IP MYHOME.50573 > STUNNEL.6697: Flags [.], ack
    1809, win 17424, length 0<br>
    23:23:08.993183 IP MYHOME.50573 > STUNNEL.6697: Flags [P.], seq
    151:493, ack 1809, win 17424, length 342<br>
    23:23:09.006506 IP STUNNEL.6697 > MYHOME.50573: Flags [P.], seq
    1809:1884, ack 493, win 7504, length 75<br>
    <b>23:23:09.007004 IP MYHOME.50573 > SERVICE.1357: Flags [S], seq
      3062456285, win 5840, options [mss 1460,nop,nop,sackOK], length 0</b><br>
    23:23:09.022762 IP MYHOME.50573 > STUNNEL.6697: Flags [.], ack
    1884, win 17424, length 0<br>
    23:23:09.278792 IP MYHOME.50573 > STUNNEL.6697: Flags [P.], seq
    493:567, ack 1884, win 17424, length 74<br>
    23:23:09.316716 IP STUNNEL.6697 > MYHOME.50573: Flags [.], ack
    567, win 7504, length 0<br>
    23:23:09.328032 IP MYHOME.50573 > STUNNEL.6697: Flags [P.], seq
    567:689, ack 1884, win 17424, length 122<br>
    23:23:09.328073 IP STUNNEL.6697 > MYHOME.50573: Flags [.], ack
    689, win 7504, length 0<br>
    <b>23:23:12.004564 IP MYHOME.50573 > SERVICE.1357: Flags [S], seq
      3062456285, win 5840, options [mss 1460,nop,nop,sackOK], length 0</b><br>
    23:23:18.006575 IP STUNNEL.6697 > MYHOME.50573: Flags [R.], seq
    1884, ack 689, win 7504, length 0<br>
    <br>
    <br>
    In bold the 2 SYN packets present in stunnel's tcpdump towards the
    service's box. The rest of the traffic. between MYHOME and STUNNEL,
    is just part of the SSL negotiation.<br>
    <br>
    So: service's box receives a SYN packet from my home IP address
    (originated from stunnel's box), and answers with a proper ACK
    packet. That's ok. But as that ACK reply has as destination an
    external IP, goes to the box's default gateway (and not to the box
    where stunnel is running) and gets lost.<br>
    <br>
    So unless I'm missing something, I think that kind both remote
    service and stunnel should be in the same server for this to work
    (as a minimun). Which leaves me in the same place I started with :(<br>
    <br>
    Rubén.<br>
    <br>
    <br>
  </body>
</html>