|ENC(4)||Device Drivers Manual||ENC(4)|
enc interface can be created at runtime
create command or by setting up a
configuration file for
enc0 interface will always exist and cannot be
Packet filtering is documented in greater detail in
pf.conf(5), however some
details relevant to filtering on the
are documented below.
pf(4) is a stateful packet
filter, which means it can track the state of a connection. It does this
States are normally
which means they can match packets on any interface. However this is a
potential problem for filtering IPsec traffic: states need to be interface
bound, to avoid permitting unencrypted traffic should the SAs expire and not
be replaced. Therefore all rules on the
interface should explicitly set “keep state (if-bound)”. For
pass in on enc0 proto ipencap from 172.25.0.45 to 220.127.116.11 \ keep state (if-bound)
enc interface does not
directly support bandwidth control via
pf(4) queueing. Instead, IPsec
packets must be tagged and the tagged packets are assigned to queues.
ipsec.conf(5) provides an
example of tag-based queueing and further information on packet tagging.
Finally, the use of translation rules to map and redirect network traffic requires some care. Packets destined to be IPsec processed are seen by the filter/translation engine twice, both before and after being IPsec processed. If a packet's translated address on the way back fails to match an existing IPsec flow, from the translated address to the original source address, it will be discarded by the filter. It is best to avoid this situation where possible, though a flow may be explicitly created to work around it.
As noted above,
tcpdump(8) may be invoked on
enc interface to see packets prior to
encapsulation and after decapsulation. For example:
# tcpdump -envps 1500 -i enc0 -l | grep 10.0.0.33 tcpdump: WARNING: enc0: no IPv4 address assigned tcpdump: listening on enc0, link-type ENC 15:05:08.934708 (authentic,confidential): SPI 0x6bcac587: \ 172.25.0.45 > 18.104.22.168: 10.9.9.28.7001 > 10.0.0.33.7000: \ [udp sum ok] udp 52 (ttl 64, id 5672, len 80) \ (ttl 64, id 30009, len 100, bad cksum 0!) 15:05:09.063517 (authentic,confidential): SPI 0x4b70c05a: \ 22.214.171.124 > 172.25.0.45: 10.0.0.33.7000 > 10.9.9.28.7001: \ [udp sum ok] udp 156 (ttl 63, id 14880, len 184) \ (ttl 51, id 19689, len 204)
The packets above show (for each direction): date, ESP (not AH), SPI, direction, and encapsulated part. The first packet is headed from 172.25.0.45 to 126.96.36.199 and the encapsulated part from 10.9.9.28 to 10.0.0.33.
Negotiations can be watched on the physical interface too:
# tcpdump -envps 1500 -i wi0 port 500 or port 4500 tcpdump: listening on wi0, link-type EN10MB 15:15:58.188747 0:2:6f:3a:3f:3e 0:10:f3:3:bd:8a 0800 226: \ 172.25.0.45.500 > 188.8.131.52.500: [udp sum ok] \ [...] attribute ENCRYPTION_ALGORITHM = AES_CBC attribute HASH_ALGORITHM = SHA attribute AUTHENTICATION_METHOD = RSA_SIG attribute GROUP_DESCRIPTION = MODP_1024 attribute LIFE_TYPE = SECONDS attribute LIFE_DURATION = 3600 attribute KEY_LENGTH = 128 [...] 15:15:59.080058 0:10:f3:3:bd:8a 0:2:6f:3a:3f:3e 0800 226: \ 184.108.40.206.500 > 172.25.0.45.500: [udp sum ok] \ [...] attribute ENCRYPTION_ALGORITHM = AES_CBC attribute HASH_ALGORITHM = SHA attribute AUTHENTICATION_METHOD = RSA_SIG attribute GROUP_DESCRIPTION = MODP_1024 attribute LIFE_TYPE = SECONDS attribute LIFE_DURATION = 3600 attribute KEY_LENGTH = 128 [...]
The attribute lines for the negotiation must match.
|February 16, 2015||OpenBSD-6.1|