This can be seen in Sample 1 at 17 (ICMPv6 rate limit may be blocking the second message).
#Hex fiend line delimityer code
So as a result the ISP device sends back an ICMPv6 unreachable with code administratively prohibited (source 2001:db8:0:3…). Fragments can not be validated until they are reassembled and reassembly opens the door for DoS-ing of the firewall besides adding latency. The ISP router is disallowing the extension headers as per standard security and performance recommendations. In each case one of these messages has and IPv6 UDP extension header and Wireshark reports this as an IPv6 fragment. 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 sample 1 see line nos 8 and 26 and sample 2 lines 1 and 5 which are received by the OpenVPN server. 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. 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).
#Hex fiend line delimityer series
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). 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.
The client and server are on different ADSL services. The connection between the client and the openVPN server is via an ISP offering native IPv6 (dual stack). It appears that some frames from the web server are jumbo frames exceeding 1500 octets even though the interfaces are configured to 1492. Web server and OpenVPN server are connected at 1Gbps through an unmanaged switch. Web server - Ubuntu running Apache and MRTG (used to generate graphical output in the form of PNG files)
#Hex fiend line delimityer pro
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. The IPv6 addresses have been anonymised by directly editing (with Hex Fiend) the PCAP files.
The results described below were generated on the following equipment and network infrastructure. 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. It appears that OpenVPN generates oversize UDP packets and passes these to the network stack. The effect of the fragmentation error is to break the tunnel connection when a graphic item is transferred or similar large size packet demand occurs. The problem does not occur when tunnel transport is using UDP over IPv4 on the same equipment and path.
It seems that openVPN 2.3.2 fragmentation calculations when using UDP over IPv6 transport are incorrect resulting in oversize packets being passed to the network stack for transmission (initially mentioned in a comment added to bug #348).
0 kommentar(er)
