|
Hello,
On Wed, 13 Feb 2002, Roberto Nibali wrote:
> > May be it is possible by adding ESP support to LVS
> > to define fwmark-based persistent virtual service that can
> > forward ISAKMP and ESP to the right VPN gateway, all in LVS-DR
> > mode? May be even AH can work with LVS-DR? One client goes
> > only to one real server. I hope the ESP protocol is not difficult
> > to add in LVS. Any thoughts from the IPSec gurus on this list? :)
>
> I'm not a IPsec guru, but how do you intend to mark the descrambled ESP
> packet and redirect it into the LVS code path? I mean as a start we
Is this correct?:
ipchains -A input -p 50 -d VIP1 -m FWM1
ipchains -A input -p UDP -s 0.0.0.0/0 500 -d VIP1 500 -m FWM1
ipvsadm -A -f FWM1 -s wlc -p
VIP1 is in fact the local secure gateway IP. The VPN
client does not care who handles the ESP traffic, we need same
keys and certificates on all real servers, not much different
from the farms with SSL real servers.
When I'm talking about LVS support for ESP I mean
ability to forward ESP and AH protocols. Currently, we like only
TCP, UDP and related ICMP, everything else is skipped and passed
to the stack (next in the netfilter's chain). But LVS can reroute
skbs if we decide so. Everything we want :) We just need a way
to correctly create connections for them. I'm still not sure
whether we need to remember the SPI.
What I want is we to check the packet before reaching the
IPSec handling (protocol handlers after INPUT chain). We can
analyze it at INPUT or PRE_ROUTING (if we move LVS there one day).
LVS can be a simple router: get the source and destination
addresses of the ESP/AH packet, lookup the connection table
and forward the ESP/AH packet without any changes to the real
server which is a IPSec terminator. No decaps, no crypto.
LVS-DR only. No LVS-NAT for the ESP/AH traffic (NAT breaks AH
and may be even ESP auth, not sure). Nothing different from the
2 ways to handle SSL traffic: termination or simple forwarding.
LVS does only forwarding, without knowing the SSL protocol.
The termination helps the scheduling to occur at Layer 5 and
above. The forwarding allows the real servers to handle more
traffic compared with the standalone box. LVS is a dumb router.
What can include the support:
- different in_get handlers (no out_get for non-LVS-NAT)
- different timeouts
The result: better internal structure in LVS to work
as an universal scheduler for different protocols. The base
should include protocol-specific conn lookup functions,
specific way to route the traffic (if needed).
> (you) could do ESP support only which would work for LVS-DR and LVS-NAT.
> I don't know if you can dequeue from a ipsec0 device? It's just a
No, no ipsec devices. Of course, if the LVS box is a VPN
gateway then LVS can schedule the traffic coming from the ipsec
devices. But it is true that the protocol number is missing as key
from the routing, this can help (at least for ESP/AH, not for
identifying the ISAKMP traffic) to correctly route the
ISAKMP/ESP/AH traffic through normal paths and the normal TCP/UDP traffic
through the respective ipsec interfaces for output but may be the
ipsec users do everything with fwmarking (if correct rp_filter
checks are needed to accept the ESP/AH traffic coming from the
remote secure gateway). May be this is difficult in 2.2 (in 2.4
there is fwmark for output routes). But what is the trick:
the fwmarking must have same usage for the both route directions:
input and output. Now, if you look at the rp_filter protection
you can see that there is no fwmark support there :))) It is
difficult to satisfy all needs :) Nobody listens and cares :)
As for the freeswan routing optimizations you mention in the
previous mail, yes, may be there is a space for such things but
I don't know the IPSec and FreeSWAN internals and still don't have
time to analyze the source code (FreeSWAN is a big code base). But
I have the feeling the things are not looking very good :) The correct
routing usage can help for problems such as PMTUd, no need for
phys-virt interface associations, may be other things...
> secondary IP IMHO. Check out [1] and Cisco's explanation on ESP and NAT
> at [2]. And before you implement it, you should read [3] and [4] :)
Yes, I see. This is the reason I don't want to play with
NAT over the ESP/AH traffic. We better only to route it. Let the
real servers (the hidden IPSec terminators) to decapsulate the
traffic. This is our goal: spread the IPSec "requests" to
many real severs. This is good for IPSec transport mode where the
real servers are, for example, the final destinations (web servers
for example) for the users' traffic. As for the tunnel mode may be
the real servers need to SNAT the client's IP if its traffic
is forwarded to the next LVS based cluster which can be a normal
web farm. The SNAT of the client's traffic can help the replies to
find their right IPSec local Secure Gateway. As result, this can
help for the FreeSWAN's "Opportunism", to build cluster of
IPSec aware real servers (is it stupid enough?).
But I see very big routing problems with FreeSWAN.
Even while the both secure gateways negotiate secure path
between two subnets (1 local and 1 remote) the result from
the default freeswan's _updown script is a destination-only route,
i.e. instead of route:
from local_net to remote_net => dev ipsecX
we see
from all to remote_net => dev ipsecX
which is not negotiated and makes difficulties for the case
where the local (always true for the local gateway with "from all")
or the remote gateway IP are part from the negotiated networks.
But this is theory. Routing theory :))) I even see users
avoiding the rp_filter protection from the external interfaces :)
> Cheers,
> Roberto Nibali, ratz
Regards
--
Julian Anastasov <ja@xxxxxx>
|
