It appears that OpenVPN generates oversize UDP packets and passes these to the network stack. The network stack will then attempt further fragmentation but the fragment uses IPv6 extension headers and these are administratively blocked by intervening firewalls which in turn issue ICMPv6 unreachable code 1 (administratively prohibited) messages. The results described below were generated on the following equipment and network infrastructure. The IPv6 addresses have been anonymised by directly editing (with Hex Fiend) the PCAP files. OpenVPN Client - Windows 7 VM running openVPN 2.3.2 (hosted on MacBook? Pro using VMware Fusion with the network in bridged mode) The addresses listed below match the modified capture file snippets as displayed by Wireshark (screen captures attached) of the modified PCAP files. Wired ethernet interface address 2001:db8:0:2. Single dual stack physical ethernet connection (eth0).OpenVPN server - Centos 6.3 running openVPN 2.3.2 with 'multihome' declared eth0 MTU configured to 1492 (for PPPoE ADSL operation).tcpdump used to capture traffic on eth0 and then filtrered to remove unrelated traffic.Web server - Ubuntu running Apache and MRTG (used to generate graphical output in the form of PNG files) ![]() ![]() Web server and OpenVPN server are connected at 1Gbps through an unmanaged switch. It appears that some frames from the web server are jumbo frames exceeding 1500 octets even though the interfaces are configured to 1492. The connection between the client and the openVPN server is via an ISP offering native IPv6 (dual stack). The client and server are on different ADSL services. Cisco routers are used on both services at the client and server ends and these are configured to allow ICMPv6 unreachable messages to support PMTUD. Only one ISP exchange/central station is traversed but this appears to be using a Cisco ASA 5500 series firewall or similar features in their router(s). The address of the device issuing the ICMPv6 unreachable messages has been partially anonymised by replacing the top 64bits with 2001:db8:0:3 It has been observed that sequence number randomisation is being applied by the ISP to IPv6 in both directions (a default feature of the Cisco ASA and some other firewalls and ISP CE routers). What we see in the samples is that an HTTP request has caused the server (192.168.1.1) to send to the browser (192.168.6.132) a large frame. In sample 1 see line nos 8 and 26 and sample 2 lines 1 and 5 which are received by the OpenVPN server. ![]() OpenVPN proceeds to encrypt the complete HTTP/TCP/IPv4 packet This will be passed to the stack using sendmsg() or sendto() function which will then complete the transport envelope resulting in the packets sent from 2001:db8:0:1… (server) to 2001:db8:0:2… (client). In each case one of these messages has and IPv6 UDP extension header and Wireshark reports this as an IPv6 fragment. The ISP router is disallowing the extension headers as per standard security and performance recommendations. Fragments can not be validated until they are reassembled and reassembly opens the door for DoS-ing of the firewall besides adding latency. So as a result the ISP device sends back an ICMPv6 unreachable with code administratively prohibited (source 2001:db8:0:3…). This can be seen in Sample 1 at 17 (ICMPv6 rate limit may be blocking the second message).
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |