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-inleft=::1leftsubnet=::0/0leftprotoport=58/34560rightprotoport=58/34816rightsubnet=::0/0right=::0connaddrfamily=ipv6authby=nevertype=passthroughauto=routepriority=1conn v6neighbor-hole-outleft=::1leftsubnet=::0/0leftprotoport=58/34816rightprotoport=58/34560rightsubnet=::0/0right=::0connaddrfamily=ipv6authby=nevertype=passthroughauto=routepriority=1