On 1/11/2016 1:49 PM, Jan Just Keijser wrote: > Hi Jeff, > > On 11/01/16 22:06, Jeff Boyce wrote: >> My additional diagnostic testing results are at the bottom. >> > my comments are also 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 > Excellent news! >> 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. >> > If you want to allow all traffic to and from the tun network(s) to be > forwarded then add something like > > iptables -A FORWARD -i tun+ -j ACCEPT > iptables -A FORWARD -o tun+ -j ACCEPT > > remember that when forwarding traffic you need to write rules for both > incoming and outgoing traffic. > > HTH, > > JJK > > Thanks for the pointers. I am doing some research now reading through the iptables man page and reading other examples. I suspect that my initial forwarding rule attempt was lacking because I was only addressing one direction and not the bi-directional nature of forwarding. If I have some time this evening I will give this a try. 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
