On Thu, 2007-10-18 at 09:35 +0200, Mitja MuE>eniD wrote: > This is the correct behaviour, as ipsec tunnel selection happens earlier in > the process than route selection, the traffic for 192.168.64.0/24 enters the > tunnel because it matches the remote subnet 192.168.0.0/16. > > Use this on the 192.168.64.1 machine to create a "bypass flow" in > ipsec.conf:
This works exceptionally well! Thank very much. Beers on us. As for correct behavior, that may be accurate from a pragmatic source code ip_output()/ip_output() standpoint, but very few IP stacks give "Directly Connected" routes lower priority than IPSec SAs. IMHO, it is important to follow the precedent set. ~BAS > flow esp from 192.168.64.0/24 to 192.168.64.0/24 type bypass > > This will prevent the traffic from 192.168.64.0/24 to 192.168.64.0/24 from > entering the tunnel. > > Mitja > > > -----Original Message----- > > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] > > On Behalf Of Brian A. Seklecki > > Sent: Thursday, October 18, 2007 2:02 AM > > To: misc@openbsd.org > > Subject: ipsec(4) routing for a branch offices > > > > On a variety of 3rd party platforms, I often establish an SA > > between two IPSec devices with a /16 of RFC 1918 space on one > > side and a /24 on the other (sometimes as much as a /19). > > > > This "uneven" size subnet arrangement prevents the need for > > full-mesh in a large corporate network. It allows for hub & spoke. > > > > I remember an OpenBSD 3.6-era bug, which I was certain was > > PR'd and fixed, that caused this configuration to fail. On a > > remote branch office policy router, I have the following > > ENCAP family routes (below) > > > > Here's the problem: > > > > 1) Traffic sourced from the internal interface > > (192.168.64.1/24) for the directly connected subnet > > 192.168.64.0/24 is transmitted accross the tunnel in ESP > > > > 2) Traffic from the locally connected subnet reaches the > > interface of the internal (64.1/24), but reply packets are > > attempted to forward accross the tunnel instead of back out > > of the physical interface > > > > Routing tables > > > > # netstat -rn -rf encap > > Encap: > > Source Port Destination Port Proto > > SA(Address/Proto/Type/Direction) > > 192.168/16 0 192.168.64/24 0 0 > > 206.210.89.200/esp/use/in > > 192.168.64/24 0 192.168/16 0 0 > > 206.210.89.200/esp/require/out > > > > # netstat -rn -f inet > > Internet: > > Destination Gateway Flags Refs Use > > Mtu Interface > > default 71.166.xxx.xxx UGS 11 173981 > > - em2 > > 71.166.245/24 link#3 UC 1 0 > > - em2 > > 192.168.64/24 link#1 UC 4 0 > > - em0 > > > > Strange as hell.... > > > > $ sudo tcpdump -i em0 -s 256 "!port 22" > > $ ping 192.168.64.100 > > PING 192.168.64.100 (192.168.64.100): 56 data bytes > > > > [but, what is seen on another terminal] > > > > [1] sudo tcpdump -i em2 -s 256 "!port 22" > > 20:00:28.610672 esp xxxxx.east.verizon.net > > > vpncxxx.pub.collaborativefusion.com spi 0x0ACAEE17 seq 89 len 116 > > > > ICMP packets giving me the old slip-a-roo out the back door >:} > > > > -- > > Brian A. Seklecki <[EMAIL PROTECTED]> > > > > > > > > IMPORTANT: This message contains confidential information and > > is intended only for the individual named. If the reader of > > this message is not an intended recipient (or the individual > > responsible for the delivery of this message to an intended > > recipient), please be advised that any re-use, dissemination, > > distribution or copying of this message is prohibited. > > Please notify the sender immediately by e-mail if you have > > received this e-mail by mistake and delete this e-mail from > > your system.
