On Thu, Nov 23, 2006 at 02:47:14PM +0100, Camiel Dobbelaar wrote: > I think this tells me that I can see unencrypted/unencapsulated traffic on > enc0.
yes. > However, with tcpdump I see this: > > 14:09:27.894326 (authentic,confidential): SPI 0x728aafc9: 86.90.xx.xx > > 62.58.xx.xx: 192.168.2.3.1264 > 192.168.1.7.8194: . [tcp sum ok] ack 139 > win 64431 (DF) (ttl 128, id 45685, len 40) (ttl 118, id 45685, len 60) > > 14:09:27.915205 (authentic,confidential): SPI 0x021e1fcd: 62.58.xx.xx > > 86.90.xx.xx: 192.168.1.131.3389 > 192.168.2.3.1182: . [tcp sum ok] ack > 177 win 65075 (ttl 127, id 59080, len 40) (ttl 64, id 46361, len 60, bad > cksum 0!) > > The encapsulation is included... that's pretty cool and handy, but I'm not > sure if that's what the manpage says. no, the encapsulation is not included, only the _information_ about the encapsulation is (it's special information in the pcap header) > So inbound traffic passes twice: first with encapsulation, and the second > time without. However, outbound traffic only passes _once_, without the > encapsulation. that's an artefact of openbsd's ipsec implementation. de-encapsulation happens in two steps, where the first step removes the esp-layer, while the 2nd step removes the ip-in-ip encapsulation for tunnel mode. > So I think the pf rules for filtering on enc0 should look like this: > # pass encapsulated traffic > pass in quick log on enc0 proto ipencap from $ext_peer_ip to $ext_if > keep state (other.single 3600) > # rules on decrypted traffic > pass in quick on enc0 from 192.168.28.28 to 192.168.42.10 port 993 keep > state > block in quick on enc0 ipsec.conf(5) tells you how to filter on enc(4) > All in all: > - the bpf view is different from the pf view > - the inbound pf view is different from outbound not really. the only difference is that pf sees both decapsulation steps. > Should pf even see the inbound ipencap traffic? Nothing much that can be > done with it, that cannot also be done on the physical interfaces... it would require some special hacks and flags and heuristics in the kernel. i don't know if this would justify the extra code, but perhaps there's a simple solution. > Shouldn't enc just carry the unencrypted/unencapsulated traffic like the > manpage says? That would make it behave far more like a "normal" > interface. it already does. you could argue, that the encapsulation information should only be printed on '-e', but that breaks backward compatibility. -m
