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

Reply via email to