id,summary,reporter,owner,description,type,status,priority,milestone,component,version,severity,resolution,keywords,cc 348,IPv6 UDP server response may select a different source address than incoming destination preventing formation of the VPN tunnel,john7000,Gert Döring,"Server is Centos 6.3 running OpenVPN 2.3.2. The network is dual stacked and single physical interface (eth0). OpenVPN is configured for IPv4 and IPv6 both for tunnel end points and transported packets. To avoid potential routing issues at the client - as it must distinguish between tunnel carrier packets and tunneled packets both destined towards the global IPv6 address of the server - and to aid with firewall security configurations, a secondary global IPv6 address has been configured on the eth0 interface for the VPN tunnel listener. To prevent the socket connect() function used by various other clients on the server (e.g. ntpd, bind, squid …) from randomly selecting the secondary IPv6 address as the source, the secondary address has been relabelled to a high value (e.g. ""ip-f inet6 addrlabel add prefix label 45""). This causes the socket address selection rule 6 of RFC 3584section 5 to ignore the secondary address whilst a primary address with a lower label value exists. OpenVPN server UDP responses are seen to come from the primary IPv6 address. Whilst this secondary address works fine with OpenVPN over TCP over IPv6 (which must reuse the same socket for statefulness) it is not working with UDP over IPv6. Tcpdump and the adjacent router ACLs show that the the response socket used by the server to reply to the client is selecting its own source address and thus using the wrong address. Any intervening semi-stateful filters such as firewalls and NAT/PAT devices will normally block UDP responses arriving from an arbitrary and different source from the traffic sent outwards. uPNP may overide this behaviour but this is not common or practical in most enterprise networks. The client itself should also be disregarding responses received to the listening UDP socket from arbitrary IP addresses other than the address used to initiate the tunnel connection. Allowing such reponses would open client to potential man-in-the-middle attacks too. UDP sockets created for the server responses should reuse the original destination address from the client as the source address for the responses.",Bug / Defect,closed,major,release 2.3.4,Generic / unclassified,OpenVPN 2.3.2 (Community Ed),"Not set (select this one, unless your'e a OpenVPN developer)",fixed,ipv6,Gert Döring