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.
