|
Hello Julian,
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
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 ;)
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.
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
Ahh, stupid me! I misread the nice ASCII chart from Henrik. Yes, of
course. The other way it's hell.
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
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 :)
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.
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
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?
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?
- different timeouts
Timeouts for what?
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?
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.
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.
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 :)
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
FreeS/WAN is huge and believe me, I'm not going to dig into their
sources. I have only one life too.
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...
According to some BSD geeks PMTU and ECN will not work with current
IPsec implementation so don't bother.
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
Agreed.
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
Yes, I initially misunderstood (or misunderstood initially).
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?).
LOL! Yes.
But I see very big routing problems with FreeSWAN.
After reading your email, I see it too.
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
... well so far nothing which wouldn't be easy to change ...
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 :)
Yes, me too on some of our packetfilters :) rp_filter isn't perfect and
sometimes also not appropriately working with complex rerouting setups
such as hidden routing or secondary IP address bounce table walking.
I get a nap now, need to sleep a while. Tomorrow everything will be very
clear and straightened out :)
Best regards and good night,
Roberto Nibali, ratz
| 