On Feb 8, 2011, at 10:20 AM, G Douglas Davidson wrote: > I'm attempting to exclude ssh traffic from host to host IPSec transport > traffic. And not having much success on the OpenBSD side (OpenBSD to > Racoon.) > > Here's what ipsec.conf looks like: > > --- ipsec.conf --- > flow esp proto tcp from any to any port 22 type bypass > > ike esp transport from 10.222.0.1 to 10.222.0.100 \ > local 10.222.0.1 peer 10.222.0.100 \ > main auth hmac-sha1 enc aes group modp1024 \ > quick auth hmac-sha1 enc aes group modp1024 > --- end ipsec.conf --- > > I've attempted to define the manual bypass flow in different places, but > whenever the transport connection takes place, it seems that the flow set up > by the ike line takes precedence: > > --- ipsecctl -s output --- > # ipsecctl -s all > FLOWS: > flow esp in from 10.222.0.100 to 10.222.0.1 peer 10.222.0.100 srcid > 10.222.0.1/32 dstid 10.222.0.100/32 type use > flow esp out from 10.222.0.1 to 10.222.0.100 peer 10.222.0.100 srcid > 10.222.0.1/32 dstid 10.222.0.100/32 type require > flow esp in proto tcp from ::/0 port ssh to ::/0 type bypass > flow esp out proto tcp from ::/0 to ::/0 port ssh type bypass > flow esp in proto tcp from 0.0.0.0/0 port ssh to 0.0.0.0/0 type bypass > flow esp out proto tcp from 0.0.0.0/0 to 0.0.0.0/0 port ssh type bypass > > SAD: > esp transport from 10.222.0.1 to 10.222.0.100 spi 0x0b68c273 auth hmac-sha1 > enc aes > esp transport from 10.222.0.100 to 10.222.0.1 spi 0xf43c72ff auth hmac-sha1 > enc aes > --- end ipsecctl -s output --- > > The result is that non-ssh traffic properly uses the esp transport flow: > > --- tcpdump with icmp ping --- > # tcpdump -i vr1 -n host 10.222.0.100 > tcpdump: listening on vr1, link-type EN10MB > 10:11:49.244065 esp 10.222.0.100 > 10.222.0.1 spi 0xf43c72ff seq 41 len 116 > 10:11:49.244400 esp 10.222.0.1 > 10.222.0.100 spi 0x0b68c273 seq 55 len 116 > 10:11:50.244212 esp 10.222.0.100 > 10.222.0.1 spi 0xf43c72ff seq 42 len 116 > 10:11:50.244549 esp 10.222.0.1 > 10.222.0.100 spi 0x0b68c273 seq 56 len 116 > --- end tcpdump --- > > Yet ssh traffic is coming in unencrypted, bypassing ipsec, but it sent back > out via the ipsec channel (not bypassing.) > > --- tcpdump with ssh traffic --- > 10:14:26.959883 10.222.0.100.49165 > 10.222.0.1.22: S 831634158:831634158(0) > win 65535 <mss 1460,nop,wscale 3,nop,nop,timestamp 609281851 0,sackOK,eol> > (DF) > 10:14:26.960191 esp 10.222.0.1 > 10.222.0.100 spi 0x0b68c273 seq 58 len 84 > 10:14:26.960531 10.222.0.100.49165 > 10.222.0.1.22: . ack 4184984667 win 65535 > <nop,nop,timestamp 609281851 1116915592> (DF) > 10:14:27.025871 esp 10.222.0.1 > 10.222.0.100 spi 0x0b68c273 seq 59 len 100 > (DF) > 10:14:27.026220 10.222.0.100.49165 > 10.222.0.1.22: . ack 22 win 65535 > <nop,nop,timestamp 609281852 1116915592> (DF) > --- end tcpdump --- > > I can't seem to find how to affect the order of flow processing. Can the > order the changed? And is it a first match or first most specific match? > > Bit confused. The idea is I'd like to be able to ssh to any box and fix a > potentially broken ipsec setup. > > Thanks for any help! > > --doug >
The solution to this issue requires that flows be specified manually, and isakmpd must be run with the "-Ka" flags. When ipsec.conf is processed, the most recent line processed becomes the first one checked, potentially overriding other rules (what happens when isakmpd is allowed to create flows). So specifying flows manually, in reverse order from how one wishes them to be checked, where the first match encountered determines what happens, is the way to go. #In this example, the ssh bypasses will be checked first, and so ssh traffic will not occur over ipsec. flow esp in from 10.222.1.13 to 10.222.0.1 type use flow esp out from 10.222.0.1 to 10.222.1.13 type require flow esp in proto tcp from 10.222.1.13 to 10.222.0.1 port ssh type bypass flow esp in proto tcp from 10.222.1.13 port ssh to 10.222.0.1 type bypass And, in messing around with this, it's even nicer to set up a default tunnel to the gateway for non local subnet traffic (and the source gateway to host traffic), while allowing local hosts with ipsec set up to use transport (rules exists on non-gateway hosts), and finally having a default for traffic between local hosts that are not on ipsec to use a bypass rule (again, rule exists on non-gateway hosts). I also set up a bypass rule for traffic moving between ipsec ports. This may be necessary with tunnels having endpoints over a local subnet. This seems to be a nice setup to protect wireless traffic via IPSec. Something along these lines on the OpenBSD gateway. flow esp from any to 10.222.1.13 peer 10.222.1.13 type require flow esp out proto udp from 10.222.0.1 port 500 to 10.222.1.13 port 500 type bypass flow esp in proto udp from 10.222.1.13 port 500 to 10.222.0.1 port 500 type bypass flow esp out proto tcp from 10.222.0.1 to 10.222.1.13 port 22 type bypass flow esp in proto tcp from 10.222.1.13 port 22 to 10.222.0.1 type bypass flow esp in proto tcp from 10.222.1.13 to 10.222.0.1 port 22 type bypass flow esp out proto tcp from 10.222.0.1 port 22 to 10.222.1.13 type bypass ike esp tunnel from any to 10.222.1.13 \ local 10.222.0.1 peer 10.222.1.13 \ main auth hmac-sha1 enc aes group modp1024 \ quick auth hmac-sha1 enc aes group modp1024 Hope this helps someone! --doug
