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