Blame | Last modification | View Log | RSS feed
# For proper IPv6 Neighbour Discovery functioning, the unicast
# reply must be sent in plaintext) even if we have an IPsec SA
# for the destination - in case the other end rebooted and is
# trying to find us. Without this policy hole, the neighbour discovery
# answer packet is caught by the kernel, which informs the IKE
# daemon via ACQUIRE and the host sends out an IKE packet, which
# does go through the UDP hole, but the other end hasn't received
# the neighbour discovery answer packet, so cannot respond to our
# IKE packet
#
# ipv6-icmp Neighbor Discovery is Type 136, Code 0. As per RFC
# 4301/5996, icmp type is put in the most significant 8 bits and
# icmp code is in the least significant 8 bits of port field.
# proto is 58 (ipv6-icmp)
# type = 136 (0x88)
# code = 0
# so "port" in protoport is 0x8800 or 34816 in decimal
# hence protoport=58/0x8800
#
# Similarly Neighbor Sollicitation is 0x8700 (34560)
conn v6neighbor-hole-in
left=::1
leftsubnet=::0/0
leftprotoport=58/34560
rightprotoport=58/34816
rightsubnet=::0/0
right=::0
connaddrfamily=ipv6
authby=never
type=passthrough
auto=route
priority=1
conn v6neighbor-hole-out
left=::1
leftsubnet=::0/0
leftprotoport=58/34816
rightprotoport=58/34560
rightsubnet=::0/0
right=::0
connaddrfamily=ipv6
authby=never
type=passthrough
auto=route
priority=1