My additional diagnostic testing results are at the bottom.
On 1/6/2016 11:38 AM, Morten Christensen wrote: > > Den 05-01-2016 kl. 19:34 skrev Jeff Boyce: >> Greetings - >> >> I have a detailed description of my issue posted over on the Forum, but >> am not getting any responses. >> >> My issue description is posted at >> https://forums.openvpn.net/topic20369.html. >> >> I believe that my problem is a routing issue, but I have exhausted my >> avenues of research and knowledge. I am hoping someone with an eye for >> routing issues might be able to spot where my issue is located and offer >> a recommendation. > > I have looked at your forum description. > You have good chances to be on the wrong list. This looks like routing > problems between your other servers and their default gateway. > > What happens when you try a traceroute from the other server .53 to > the vpn-servers tunnel ip 10.9.8.1 ? > > Have you considered starting with the simple solution no. 3, and if > that works go on with no. 4 ? > > -- > Morten Christensen > > I started with the easiest tests first. Selva had recommended that I verify that the Windows client received and properly setup the pushed route to the 192.168.112.0/24 subnet. The routing table on the Windows client before and after establishing the VPN connection is listed below. *Before VPN Connection (Windows client route print)* IPv4 Route Table =========================================================================== Active Routes: Network Destination Netmask Gateway Interface Metric 0.0.0.0 0.0.0.0 192.168.123.2 192.168.123.111 10 127.0.0.0 255.0.0.0 On-link 127.0.0.1 306 127.0.0.1 255.255.255.255 On-link 127.0.0.1 306 127.255.255.255 255.255.255.255 On-link 127.0.0.1 306 192.168.56.0 255.255.255.0 On-link 192.168.56.1 276 192.168.56.1 255.255.255.255 On-link 192.168.56.1 276 192.168.56.255 255.255.255.255 On-link 192.168.56.1 276 192.168.123.0 255.255.255.0 On-link 192.168.123.111 266 192.168.123.111 255.255.255.255 On-link 192.168.123.111 266 192.168.123.255 255.255.255.255 On-link 192.168.123.111 266 224.0.0.0 240.0.0.0 On-link 127.0.0.1 306 224.0.0.0 240.0.0.0 On-link 192.168.56.1 276 224.0.0.0 240.0.0.0 On-link 192.168.123.111 266 255.255.255.255 255.255.255.255 On-link 127.0.0.1 306 255.255.255.255 255.255.255.255 On-link 192.168.56.1 276 255.255.255.255 255.255.255.255 On-link 192.168.123.111 266 =========================================================================== Persistent Routes: Network Address Netmask Gateway Address Metric 0.0.0.0 0.0.0.0 192.168.123.2 Default =========================================================================== *After VPN Connection (Windows client route print)* C:\>ipconfig Ethernet adapter Local Area Connection 2: Connection-specific DNS Suffix . : Link-local IPv6 Address . . . . . : fe80::44cc:5041:5d8d:ae76%9 IPv4 Address. . . . . . . . . . . : 10.9.8.6 Subnet Mask . . . . . . . . . . . : 255.255.255.252 Default Gateway . . . . . . . . . : > added routes IPv4 Route Table =========================================================================== Active Routes: Network Destination Netmask Gateway Interface Metric 0.0.0.0 0.0.0.0 192.168.123.2 192.168.123.111 10 > 10.9.8.1 255.255.255.255 10.9.8.5 10.9.8.6 31 > 10.9.8.4 255.255.255.252 On-link 10.9.8.6 286 > 10.9.8.6 255.255.255.255 On-link 10.9.8.6 286 > 10.9.8.7 255.255.255.255 On-link 10.9.8.6 286 127.0.0.0 255.0.0.0 On-link 127.0.0.1 306 127.0.0.1 255.255.255.255 On-link 127.0.0.1 306 127.255.255.255 255.255.255.255 On-link 127.0.0.1 306 192.168.56.0 255.255.255.0 On-link 192.168.56.1 276 192.168.56.1 255.255.255.255 On-link 192.168.56.1 276 192.168.56.255 255.255.255.255 On-link 192.168.56.1 276 > 192.168.112.0 255.255.255.0 10.9.8.5 10.9.8.6 31 192.168.123.0 255.255.255.0 On-link 192.168.123.111 266 192.168.123.111 255.255.255.255 On-link 192.168.123.111 266 192.168.123.255 255.255.255.255 On-link 192.168.123.111 266 224.0.0.0 240.0.0.0 On-link 127.0.0.1 306 224.0.0.0 240.0.0.0 On-link 192.168.56.1 276 224.0.0.0 240.0.0.0 On-link 192.168.123.111 266 > 224.0.0.0 240.0.0.0 On-link 10.9.8.6 286 255.255.255.255 255.255.255.255 On-link 127.0.0.1 306 255.255.255.255 255.255.255.255 On-link 192.168.56.1 276 255.255.255.255 255.255.255.255 On-link 192.168.123.111 266 > 255.255.255.255 255.255.255.255 On-link 10.9.8.6 286 =========================================================================== Persistent Routes: Network Address Netmask Gateway Address Metric 0.0.0.0 0.0.0.0 192.168.123.2 Default =========================================================================== This appears to be correct. Next, I followed the suggestion by Gert to run Wireshark on the TUN interfaces. So I started with the TUN interface on the Windows client box. *Wireshark on remote Windows Client during ping to 192.168.112.53 * No. Time Source Destination Protocol Info 1 16:14:13.608219 10.9.8.6 192.168.112.53 ICMP Echo (ping) request (id=0x0001, seq(be/le)=21/5376, ttl=128) Frame 1: 74 bytes on wire (592 bits), 74 bytes captured (592 bits) Ethernet II, Src: 00:ff:dc:92:57:17 (00:ff:dc:92:57:17), Dst: 10.9.8.5 (00:ff:dd:92:57:17) Internet Protocol, Src: 10.9.8.6 (10.9.8.6), Dst: 192.168.112.53 (192.168.112.53) Internet Control Message Protocol No. Time Source Destination Protocol Info 2 16:14:13.665459 10.9.8.1 10.9.8.6 ICMP Destination unreachable (Host administratively prohibited) Frame 2: 102 bytes on wire (816 bits), 102 bytes captured (816 bits) Ethernet II, Src: 10.9.8.5 (00:ff:dd:92:57:17), Dst: 00:ff:dc:92:57:17 (00:ff:dc:92:57:17) Internet Protocol, Src: 10.9.8.1 (10.9.8.1), Dst: 10.9.8.6 (10.9.8.6) Internet Control Message Protocol < repeated 4 times > Reading this output, the "host administratively prohibited" phrase caught my attention, as it implied to me that the system knew the proper routing, but that the packet was being administratively blocked (ie., by a firewall). So then I had to figure out which firewall, on which box within the packet route was causing the problem. Looking back at my original post I had listed the firewall rules on the VPN box and speculated that I might need an accept rule on the Forward Chain. So I took a shot and changed the default setting on the Forward Chain of my VPN box to ACCEPT ALL, rather than DENY ALL. Once I made that change I could ping any box on the LAN behind the VPN box. Examples below. * **Pings from remote Windows Client connected to VPN* C:\HomeFiles>ping 192.168.112.53 (other server behind VPN server) Pinging 192.168.112.53 with 32 bytes of data: Reply from 192.168.112.53: bytes=32 time=57ms TTL=62 Reply from 192.168.112.53: bytes=32 time=53ms TTL=63 Reply from 192.168.112.53: bytes=32 time=54ms TTL=63 Reply from 192.168.112.53: bytes=32 time=56ms TTL=63 Ping statistics for 192.168.112.53: Packets: Sent = 4, Received = 4, Lost = 0 (0% loss), Approximate round trip times in milli-seconds: Minimum = 53ms, Maximum = 57ms, Average = 55ms C:\HomeFiles>ping 192.168.112.101 (desktop box behind VPN server) Pinging 192.168.112.101 with 32 bytes of data: Reply from 192.168.112.101: bytes=32 time=57ms TTL=126 Reply from 192.168.112.101: bytes=32 time=59ms TTL=127 Reply from 192.168.112.101: bytes=32 time=55ms TTL=127 Reply from 192.168.112.101: bytes=32 time=57ms TTL=127 Ping statistics for 192.168.112.101: Packets: Sent = 4, Received = 4, Lost = 0 (0% loss), Approximate round trip times in milli-seconds: Minimum = 55ms, Maximum = 59ms, Average = 57ms Now, I don't want to leave my firewall with a default Accept All setting on the forwarding chain, so I need to identify a rule specific to the packet type / traffic that I want to allow. I am little less knowledgeable on firewall rules than routing so if someone could provide a suggestion here I would appreciate it. I tried making a rule that allowed all UDP TUN traffic, but that blocked my ping again. I think then I tried adding a port specific rule, but that didn't help either. At that point I ran out of time to conduct any additional tests. If someone can point me in the right direction to create a specific firewall rule for the forward chain I would be grateful. My thoughts right now are that maybe that previous detailed Wireshark capture will help me identify the specifications for a firewall rule (have to go back and look at that again). Once I get this all figured out I will post a complete summary back to my original forum post so that others may benefit from my educational experience. Thanks. Jeff -- Jeff Boyce Meridian Environmental www.meridianenv.com ------------------------------------------------------------------------------ Site24x7 APM Insight: Get Deep Visibility into Application Performance APM + Mobile APM + RUM: Monitor 3 App instances at just $35/Month Monitor end-to-end web transactions and take corrective actions now Troubleshoot faster and improve end-user experience. Signup Now! http://pubads.g.doubleclick.net/gampad/clk?id=267308311&iu=/4140 _______________________________________________ Openvpn-users mailing list Openvpn-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/openvpn-users
