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 ------------------------------------------------------------------------------ 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
