> No, in a security gateway IPSEC sits at the firewall level -- sockets
> are not involved, because the traffic is coming from elsewhere, not
> from local users.
>
> (We do wish to support local users with FreeS/WAN, but our single most
> important application is in security gateways, because such a gateway can
> encrypt the traffic of an entire subnet without requiring changes to the
> software on every single computer in the subnet.)
You could explain this from the very beginning...
OK, now I understand why we did not understand one another, when
talking about importance of API. Apparently, proxy need not any API. 8)
Proxy case is too much simpler than full IPsec, so that it is evident
that you cannot provide full IPsec to local users, if you have only proxy code.
You are not alone. You share the problem with people, who want to route
local packets depending not only on IP addresses.
You have menu of two chices. The first: prepare patch, removing ip_build_xmit
from kernel and replacing it with dumb large skb allocation and copy to it.
Remove all the calls to ip_fragment from kernel, they are too dangerous
for IPsec. Catch huge skbs by output firewall chain (FW_QUEUE), transform,
fragment and send. Then you will have not broken "bump in the stack" at least.
The second: if you do not want to touch kernel, than you will have to make
even more work. Namely, all the packets are catched by FW_QUEUE, but fragments
are queued, packet is defragmented, transformed and sent. It is dirty
work, but some firewall vendors really do it.
Note that you should not touch routing and create interfaces
in both cases. You sit on top of routing and use it to route
transformed packets. If you add some fake routes, you break it
inevitably.
Alexey
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/