I am fairly certain it can not be done now, and would probably be a massive task, but I am curious as to any engineering solution there might be..
A colleague whose Cisco SSL accellerators had not arrived in time brought this up. They need an (incoming) L4 loadbalancer, that retains the real remote IP (billing, country codes etc) and handles SSL on the external facing interface, and plain TCP/IP on internal.
IPfilter and l4ip would take care of the L4 loadbalancing no problem, and retain the external IPs. However, the SSL part is tricky. If you drop any one of the criteria, it's not a big problem as well.
Naturally, one could just run stunnel, or similar bouncers, but then you would lose the real external IP. [1]
Perhaps some clever, multiple, localhost RDRs could accomplish the same thing, external -> RDR -> stunnel -> RDR -> internal .. but I am unsure about this.
The Cisco solution is that they pulled SSL into their "kernel", but this might not be as feasable on Solaris, *BSD or similar IPFilter OS's.
I vaguelly recall IPFilter having the capability of calling a userland processes from its filter matches, is that the case?, can that be used?
[1] stunnel has a -T hack to re-write the packets with the external IP again, but is not supported by the OS's that are considered acceptable here. (Trying to avoid OS flame war).
-- 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)
