Alexey Kuznetsov writes: > Probably, you are not aware that "standard IPsec tunnel device", > if it is created: > > 1. Probably, will not accept fragmented frames, because IPsec cannot > handle them
IPsec can handle them, though not particularly smoothly if the IPsec tunnel is only supposed to carry a particular port&protocol combination. > 2. Probably, will have undefined MTU (65536), because of 1 An MTU that is more likely to make most things work (at least over Ethernet) is ETH_DATA_LEN - MAX_SA_LEN where MAX_SA_LEN is however much is required for IPsec (something like IP + UDP if NAT-T + ESP header + IV + padding + ESP trailer). The simplest thing is to just statically configure it. However, some implementations dynamically calculate the IPsec device MTU based on the maximum size required by any of the IPsec SAs that will go over the interface, using either a pessimistic (255) or optimistic (2) padding estimate. This can cause problems for OPSF adjacency if each side arrives at a different MTU but that can be handled by either manually configuring the device MTU or explicitly configuring the MTU that OSPF will advertise (I think Quagga supports that). > Actually, this is the reason why it is not implemented. > It is dirty business. :-) And the person, who implements this, > has to be really... unscrupulous. :-) Exactly the same issue occurs if one implements IPsec (or any other encryption method) in user-level using a tun/tap device. Consequently while I agree that fragmentation causes an additional level of problems if one wants to have port/protocol based selectors in IPsec, I believe that most (but not all) VPN users are quite satisfied with policies containing all traffic, all ports and so will not encounter any IPsec specific problems. - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
