I think the problem is that the flow with the most specific source-network wins
Am Donnerstag, 28. Juli 2011 um 14:24 schrieb Pawel Wieleba: > On Tue, Jul 19, 2011 at 09:33:49PM +0100, Stuart Henderson wrote: > > On 2011/07/19 21:45, Markus Friedl wrote: > > > All OpenBSD versions should have this problem as it's due to the way how > > > IPsec-flows are encoded in the routing table and I could not find and easy > > > fix. > > > > The easiest fix if you control both ends is probably to just use > > gif(4) tunnels. > > I do not control both ends. > > > For people who don't control both ends, RFC3884 IIPtran would be a way > > to handle this. IPsec is negotiated as for tunnel mode, but when setting > > things up in the kerneel, rather than adding flows to attract the > > traffic, you actually setup a gif(4) to handle the traffic according > > to the normal routing table, then transport mode is used to encrypt > > it - the resulting packet format is compatible with a normal client > > in tunnel-mode. > > Thank you for the tip. I do not have too many flows (almost 100), but > creating 50 gif interfaces makes configuration little more complex. > The potential and huge easiness of VPN configuration using ipsec.conf > or iked.conf induced me to create this PR. It would be comfortable to > have the encap routing table acting in the simmilar manner as inet, > where the IP frame is sent to the peer which has the most narrow > network mask. > > Thank you for your time. > > Best Regards, > Pawel Wieleba > > BTW. The http://cvs.openbsd.org/cgi-bin/query-pr-wrapper run from > http://www.openbsd.org/query-pr.html does not work.
