I just tried this source code to see if I could get anywhere towards an
SSL-accellerator setup with IPFilter. I am unsure how it is supposed to work, I
was under the impression that it will intercept a connection to a listening
socket, but still retail the original peer IP?
Incoming rule, as suggested by proxy.c : Note I can not use localhost as this is
Solaris, so I RDR to the internal interface.
"rdr e1000g0 0.0.0.0/0 port 7100 -> 172.20.11.254 port 1 tcp"
I have inetd spawning proxy as suggested by proxy.c
"tcpmux stream tcp nowait root /usr/local/bin/proxy proxy e1000g1"
Giving it a "argv[1]" as that determines whether or not "do_nat_out" is called.
e1000g1 in this case is the internal interface. But I have tried both.
I also have inetd listening on 7100 as the final destination, which is my own
program calling getpeername() and getsockname().
If I telnet directly to 7100 (by disabling RDR):
# telnet 210.172.133.140 7100
OK Hello 210.my.ext.IP:62282 - you are connected to 210.172.133.140:7100
If I connect from an external host, with RDR back in:
# telnet 210.172.133.140 7100
local IP# to use: 210.172.133.140
local port# to use: 39431
remote end for connection: 210.172.133.140,7100
OK Hello 210.172.133.140:39431 - you are connected to 210.172.133.140:7100
The only "ipnat -l" entry I get during that time is:
RDR 172.20.11.254 1 <- -> 210.172.133.140 7100 [210.my.ext.IP 62292]
So it seems not to do anything, or at least, not what I expect it to do,
rendering it somewhat useless to me.
(It is curious that getsockname responds with the external IP 210.172.133.140,
and not with the RDR destination "172.20.11.254").
Anything obvious?
Printing out nlp->real_ip under "local port to use" I still get the IPfilter
external IP "210.172.133.140". I would have expected my "210.my.ext.IP" there.
--
Jorgen Lundman | <[EMAIL PROTECTED]>
Unix Administrator | +81 (0)3 -5456-2687 ext 1017 (work)
Shibuya-ku, Tokyo | +81 (0)90-5578-8500 (cell)
Japan | +81 (0)3 -3375-1767 (home)
