[prev in list] [next in list] [prev in thread] [next in thread] 

List:       ipfilter
Subject:    Re: Ipfilter with SSL?
From:       Jorgen Lundman <lundman () lundman ! net>
Date:       2006-05-18 5:35:52
Message-ID: 446C07B8.1000506 () lundman ! net
[Download RAW message or body]


Sorry for the noise people.

My original idea does not work, since I can not send packets to an RDR on the 
same box, at least, it does not work for me.

rdr e1000g0 0.0.0.0/0 port 7100 -> 172.20.11.5 port 7100 tcp round-robin

external host:
# telnet 210.172.133.140 7100
OK Hello 210.xxx.xxx.xxx:64285 - you are connected to 172.20.11.5:7100

On the IPFilter box:
telnet 210.172.133.140 7100
telnet: Unable to connect to remote host: Connection refused
telnet 172.20.11.254 7100
telnet: Unable to connect to remote host: Connection refused
telnet 127.0.0.1 7100
telnet: Unable to connect to remote host: Connection refused

Does this mean for stunnel to be able to connect to a bunch of servers in a 
round-robin RDR, I either have to build-in knowledge of the members to stunnel, 
or, sandwich the RDR-rr rules on a server between stunnel and application servers?

Or, Would it be possible to add code in stunnel to lookup the RDR, and its 
members, that it should use to build the NAT rule in stunnel as needed? the 
sample/proxy.c seems to already look up its own RDR, to fish out the real 
external IP:port.

I can still do the stunnel patch for a simple 1-1 proxy though.

Lund




Jorgen Lundman wrote:
> 
> If I were to expand on this, can I just run this past you experts so 
> that I am going down the right road.
> 
> The end rule should be a round-robin style rule, which is populated by 
> "l4ip" process, and it would be nice if this rule could be left to be 
> maintained by l4ip, and not "written" by stunnel (sample/proxy.c) code. 
> (Since I don't want to have to deal with knowing what members are UP in 
> stunnel patch)
> 
> To be compatible, it can't really use localhost, and in addition to 
> this, to function with IPFilter it has to pass from one interface to 
> another. (Still the case right?).
> 
> Ports here are just examples.. should be on for any TCP+SSL protocol.
> 
> So, perhaps something like:
> 
> 1] ext0:80 RDR -> int0:80
> 2] stunnel listens on int0:80, with the extra patch to fudge src IP, 
> connects to
> 3] ext0:81 RDR+rr -> int0 -> one-cluster-host:81
> 
> 1] is static rule.
> 3] is populated by l4ip to add/remove members with RDR + round-robin.
> 
> External SSL connection comes in to port 80, is redirected to stunnel. 
> stunnel handles the SSL->plain conversion, and connects to ext:81 with 
> the proxy source patch added to ensure that the connection appears to 
> come from external IP. It connects to external interface so that the 
> packet travels through to leave on the internal interface, to one of the 
> members listed in the RDR+rr rules.
> 
> Return packets are sent to external IP.. I assume here, that ipfilter 
> picks up on this, sends it to ext0 interface where stunnel is, and the 
> rest is standard.
> 
> Would that work? It might be desirable to add ipf.conf rules to stop 
> direct connections to :81, or, alias on another non-routable IP to 
> simulate localhost.
> 
> 
> Lund
> 
> 
> Carson Gaspar wrote:
> 
>> --On Wednesday, May 17, 2006 11:44 AM +0900 Jorgen Lundman 
>> <lundman@lundman.net> wrote:
>>
>>> But to me that still feels very hacky. It would be more desirable if you
>>> could make a competing "black box" solution with IPFilter+SSL, and not
>>> require the SSL overhead on the client servers at all (which is one of
>>> the points of SSL accellerators).
>>
>>
>>
>> You can. You just need to add support for IP filter to stunnel. See 
>> samples/proxy.c in the source distribution for an example of the NAT 
>> API used to accomplish this.
>>
> 

-- 
Jorgen Lundman       | <lundman@lundman.net>
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)
[prev in list] [next in list] [prev in thread] [next in thread]