On Fri, Feb 28, 2014 at 9:52 AM, Stuart Henderson <[email protected]> wrote: > > I'm sure it's a bug, I suspect possibly in some dark corner of radix.c. > I haven't heard of anybody else hitting this same problem so in a way > I'm quite glad it's not just me :) > > On box1 you have these flows > > 192.168.150.13/32 0 192.168.150.16/32 0 0 192.168.150.13/esp/use/in > 192.168.150.16/32 0 192.168.150.13/32 0 0 > 192.168.150.13/esp/require/out > > which ought to only match "proto esp" traffic between 192.168.150.13 and > 192.168.150.16, but it actually matches "proto tcp port 22" traffic > between 192.168.150.16 and itself (192.168.150.16). > > This is at least a potentially useful extra data point that it happens > with iked as well as manual keying. > > The common factor between your case and mine is that the flow which is > attracting traffic which it shouldn't, uses "proto esp". >
Yep, agreed. I was not sure to understand why TCP port 22 is "sucked" into that rule. It shouldn't as you say. > Workaround, well, it only seems to affect the local address in the > flow (i.e. in your case 192.168.150.16) so if you have another locally > configured address that you can change the flow to use, you might be able > to get around it...not nice though. > It also actually affects "real" public IP addresses. Before sending this first email, I had the same problem on 2 OpenBSD boxes 5.4-release (GENERIC.MP i386) with each a public static IP address. Both are linked through ikev2 / IPsec with the same rulesets as above (modulo the IP addresses of course). Each box runs SSH and NSD. While there is no issue to reach the box on port 22 and 53 from the outside when the VPN is up, it is not possible to access the service on the box itself (I tried with PF enabled, disabled and basically using the same procedure as my first email and conclude to the same result: impossible to reach locally the service when the VPN is up; the traffic is sent to enc0 and tcpdump produces the same output on enc0 (again modulo the IP addresses)) I thought something was wrong with my setup so tried to reproduce the problem on a local subnet (192.168/16) and managed to. Using another extra public address on each box is not really an option nor creating a vether interface on each box as I was intentionally creating a "site to site" VPN on purpose. I am kind of stuck. Will try to look at radix.c but if you have any additional pointers or tips, that would be greatly appreciated.. In a way, I am also glad to hear you are facing some similar issue :) Cheers, Josh
