![\"\"](\"https:\/\/kudzia.eu\/b\/wp-content\/uploads\/2020\/12\/black-hole-UDP.png\")
<\/p>\nUDP packets sent from specific source port, with public source IP address do not reach specific destination port of the public destination IP address. changing any of the parameters [ usually source port ] – fixes the issue.<\/p>\n
i’ve observed this phenomenon multiple times for long-running OpenVPN and Wireguard VPNs encapsulating encrypted traffic in UDP packets. i cannot put my finger on the actual case of it besides saying it’s not in our infrastructure, it’s somewhere in ISPs networks. i know it’s not on ‘my’ side because i’ve sniffed packets on ISP-facing interfaces on both ends of the VPN tunnel. it does not sound like typical tcam corruption in a router – because that would affect only pair of source<>destination IP addresses. also – the ‘black hole’ i’ve observed many times i always unidirectional.<\/p>\n
<\/p>\n
i’ve seen it happening for mix of different connection types [ different datacenters, different business and home ISPs ], in different countries. i’ve accepted it as a fact of life that needs to be work-around’ed rather than solved. since changing of source port is usually simplest and sufficient – i’m letting both OpenVPN and Wireguard to randomize that parameter and i’m just adding watchdogs wherever i have that type of tunnel. watchdog is just on the ‘remote’ end – at machine ‘dialing up’ to the VPN server.<\/p>\n
\/etc\/cron.d\/openvpnwatchdog has as many lines as VPN tunnels:<\/p>\n
\r\n*\/5 * * * * root \/usr\/local\/bin\/openvpnTunnelWatchdog.sh 169.254.1.15 namveOfVPN0 > \/dev\/null 2>&1\r\n*\/5 * * * * root \/usr\/local\/bin\/openvpnTunnelWatchdog.sh 169.254.1.71 namveOfVPN1 > \/dev\/null 2>&1\r\n<\/pre>\n1st argument – tells what IP is assigned to the remote end of the encrypted tunnel,<\/p>\n
where nameOfVPN1 is taken from the output of this command:<\/p>\n
\r\nroot@vpnclient:~# systemctl list-units --type=service|grep openvpn\r\nopenvpn.service loaded active exited OpenVPN service\r\nopenvpn@namveOfVPN0.service loaded active running OpenVPN connection to implantis.vpn.kudzia.eu\r\nopenvpn@namveOfVPN1.service loaded active running OpenVPN connection to implantis.vpn.kudzia.eu\r\n<\/pre>\nthe \/usr\/local\/bin\/openvpnTunnelWatchdog.sh script itself:<\/p>\n
\r\n#!\/bin\/bash\r\nif [ $# -lt 2 ] ; then\r\n echo syntax:\r\n echo "openvpnTunnelWatchdog.sh ip tunel_name [ eg. namveOfVPN1 ]"\r\n exit 1\r\nfi\r\n\r\nip=$1\r\nservice=$2\r\n\r\n# "( flock .. ; .. ) 200> " prevents piling up of multiple script instances running in parallel in case there's problem with service restart \/ pinging\r\n# based on http:\/\/stackoverflow.com\/questions\/7057234\/\r\n(\r\nflock -n -e 200 || exit 1\r\n\r\necho $ip\r\necho $service\r\n\r\nping -i 0.2 $ip -c 5\r\nif [ $? -eq 0 ]; then\r\n echo "everything is ok"\r\nelse\r\n echo "restarting vpn: " + $service\r\n systemctl restart openvpn@$service.service\r\n\r\n if [ $? -ne 0 ]; then\r\n echo "problems with restarting tunnel: " + $service\r\n fi\r\nfi\r\n) 200 >\/tmp\/openvpnTunnelWatchdog-$service\r\n<\/pre>\nequivalent for wireguard – \/etc\/cron.d\/wireguardwatchdog<\/p>\n
\r\n*\/5 * * * * root \/usr\/local\/bin\/wireguardWatchdog.sh 2001:470:614d:ffff::1 \/etc\/wireguard\/wg1.conf > \/tmp\/x 2>&1\r\n*\/5 * * * * root \/usr\/local\/bin\/wireguardWatchdog.sh 192.168.2.1 \/etc\/wireguard\/wg0.conf > \/dev\/null 2>&1\r\n<\/pre>\n\/usr\/local\/bin\/wireguardWatchdog.sh:<\/p>\n
\r\n#!\/bin\/bash\r\n\r\nif [ $# -lt 2 ] ; then\r\n echo syntax:\r\n echo "wireguardWatchdog.sh ipToPing \/etc\/wireguard\/wgX.conf"\r\n exit 1\r\nfi\r\n\r\nip=$1\r\nconfig=$2\r\n\r\n# "( flock .. ; .. ) 200> " prevents piling up of multiple script instances running in parallel in case there's problem with service restart \/ pinging\r\n# based on http:\/\/stackoverflow.com\/questions\/7057234\/\r\n(\r\nflock -n -e 200 || exit 1\r\n\r\necho $ip\r\necho $service\r\n\r\nping -i 0.2 $ip -c 5\r\nif [ $? -eq 0 ]; then\r\n echo "everything is ok"\r\nelse\r\n echo "restarting vpn: " + $service\r\n wg-quick down $config\r\n wg-quick up $config\r\nfi\r\n) 200>\/tmp\/wg-$ip\r\n<\/pre>\n","protected":false},"excerpt":{"rendered":"UDP packets sent from specific source port, with public source IP address do not reach specific destination port of the public destination IP address. changing any of the parameters [ usually source port ] – fixes the issue. i’ve observed this phenomenon multiple times for long-running OpenVPN and Wireguard VPNs encapsulating encrypted traffic in UDP […]<\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[51],"tags":[47,111,89,110],"class_list":["post-3140","post","type-post","status-publish","format-standard","hentry","category-unimportant","tag-linux-networking","tag-mysteries","tag-openvpn","tag-wireguard"],"_links":{"self":[{"href":"https:\/\/kudzia.eu\/b\/wp-json\/wp\/v2\/posts\/3140","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/kudzia.eu\/b\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/kudzia.eu\/b\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/kudzia.eu\/b\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/kudzia.eu\/b\/wp-json\/wp\/v2\/comments?post=3140"}],"version-history":[{"count":9,"href":"https:\/\/kudzia.eu\/b\/wp-json\/wp\/v2\/posts\/3140\/revisions"}],"predecessor-version":[{"id":3303,"href":"https:\/\/kudzia.eu\/b\/wp-json\/wp\/v2\/posts\/3140\/revisions\/3303"}],"wp:attachment":[{"href":"https:\/\/kudzia.eu\/b\/wp-json\/wp\/v2\/media?parent=3140"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/kudzia.eu\/b\/wp-json\/wp\/v2\/categories?post=3140"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/kudzia.eu\/b\/wp-json\/wp\/v2\/tags?post=3140"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}