|
Hello,
On Thu, 14 Feb 2002, Roberto Nibali wrote:
> > 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
>
> Yes [besides that no RS are defined :)]. What I think you need to do
Yes, the non-interesting part :)
> then is to disable re-keying (set rekey=no) so we don't need to support
> a back connection request for key exchange. Like this we have cleaned
> the peer-2-peer connection a little bit by allowing it only into one
> direction. It's like with identd ;)
This should be investigated, what behaviour has the ISAKMP
traffic.
> > 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.
>
> Yes, if we do IPsec termination on LVS.
This is a non-LVS issue, the termination on the LVS box.
I mean, all RS have same keys, they are terminators.
> > 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
>
> Send it to QUEUE target and do the decryption in user space :)
:)
> > to correctly create connections for them. I'm still not sure
> > whether we need to remember the SPI.
>
> Yes, for rerouting you need to extend the routing code to remember the
> SPI unless you can setup a new SA in the POST_ROUTING by IP-IP tunneling
May be only the client's SPIs, if the client masquerades other
VPN clients. May may be there are same issues with unknown SPI values
at the first packets, I don't remember how was handled this in the
VPN Masquerade 2 years ago, I have to check it.
> and a IP4 but then I think you need to disable TCP checksumming. I'm not
> sure there. If you have a SA mismatch you need to renegotiate it which
> is impossible to handle in LVS unless you create a SA database to create
> new SPI's from a hashed pool. It would be easy, if everything would be
> IPv6 :)
Hm, something to investigate ...
> > 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).
>
> You need an SA pool called SPD (Security Policy Database) where you
> store the SPI information for post processing. If we decide to strip of
> some daisy-chained headers from AH we need to make sure that
> checksumming is disabled or the IPsec endpoint will not accept the
> packet anymore (needs to be tested). But at least we would not need the
> SPI information.
Yes, I prefer this case
> > 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.
>
> If this works, I'm glad. I mean, try it. For you this shouldn't be more
> than 3 evenings of coding and then we will see. I'm too unfamiliar with
May be in the next days/weeks, there is another pending
stuff to complete... But until then we will investigate the
internals.
> the whole IPsec stuff how it works internally. Maybe asking on the
> FreeS/WAN developer list could help instead of my wild guesses.
>
> > 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.
>
> Well, true enough actually. Except that for SSL you have a port
> information in the TCP header whereas with ESP/AH haven't anything like
> that. How do you intend to apply the persistency template if there is no
> port information?
I prefer not to make the real servers' routing more difficult
by allowing different client connections to reach different real
servers but this is TOCHECK.
> > 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.
>
> Agreed.
>
> > What can include the support:
> >
> > - different in_get handlers (no out_get for non-LVS-NAT)
>
> In regard to netfilter?
Nothing special, may be.
> > - different timeouts
>
> Timeouts for what?
For the "connection", I'm not sure how much long should
last one ISAKMP or ESP entry in LVS.
> > 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).
>
> But then you need to change the connection templates, or am I wrong?
Yes, ESP and AH will use different keys. Note that the
fwmark services don't care for protocols, they are protocol
independent.
> > 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
>
> Well you could hash the information with the SPI and then take the
> resulting hash value as routing key.
Yes, may be saddr->daddr,sSPI can be a hash key
> > 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
>
> Disable rp_filtering. rp_filtering should be done in front of the LVS by
> a packetfilter.
Agreed.
> > 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 :)
>
> I know, I'm sure according to ANK this is complete and utter crap again
> which will not be used by anyone and the change of LVS ever get accepted
> into the mainline kernel is gone :)
:)
> Best regards and good night,
> Roberto Nibali, ratz
Regards
--
Julian Anastasov <ja@xxxxxx>
|
