Menu
▾
▴
Re: [Openvpn-users] Server can't ping client
|
From: Jan J. K. <ja...@ni...> - 2008-09-03 13:32:44
|
Hi Tim, Tim Boyer wrote: >> Hi Tim, >> >> I just realized: what you are saying is that you can ping any >> machine at >> the client side except the VPN client itself? If so, then >> you're looking >> at a source routing issue. Read the archives for the proper >> 'iproute2' >> magic to handle this issue. A very crude method to overcome >> this is to >> use iptables. >> On the other hand, do you really need to be able to ping the VPN >> client's LAN interface? what for? >> >> >> > > Nope; haven't gotten that far. I figure that routing and subnets are > something to be done after I get basic connectivity working. > > princeton's at 192.168.4.78, and when I bring up OpenVPN, also at > 192.168.5.1. > yamaguchi's at 192.168.42.254, and 192.168.5.6. > > >From yamaguchi, I can ssh princeton, or ping it, or anything else. So ssh > tim@princeton gets me over there. > > >From princeton, I can't do any of that to yamaguchi. I can ping > 192.168.5.6, and I can ssh to tim@192.168.5.6 - but not to tim@yamaguchi, or > tim@192.168.42.254. > > After I get basic point-to-point connectivity, _then_ I'll work on getting > to the subnets behind. I just figured I'd better walk before I try to run. > > Hope this clears things up. > > > aha I understand... hmmmm still, can you the following experiment (coz I am not yet sure what is failing at this point, openvpn or a network routing thingie): - on yamaguchi, run tcpdump -nnel -i eth1 -s 0 icmp - then on princeton, try ping 192.168.42.254 - then try ping 192.168.42.1 (or any other host on the yamaguchi lan) and can you mail me (or post) whatever tcpdump is reporting.... finally, just to make sure, waht is the output of iptables -t nat -L -n -v are there any rules in the POSTROUTING chain? cheers, JJK > > >> Tim Boyer wrote: >> >>> Jan - >>> >>> >>> >>>> can you disable the firewall at both ends? or alternatively, >>>> can you add >>>> a firewall entry >>>> iptables -I FORWARD -i tun+ -j ACCEPT >>>> iptables -I FORWARD -o tun+ -j ACCEPT >>>> >>>> >>>> >>> Both sides have that in the FORWARD. Firewall looks like so: >>> >>> ### OpenVPN >>> -A INPUT -p udp --dport 1194 -j ACCEPT >>> -A INPUT -i tun+ -j ACCEPT >>> -A FORWARD -i tun+ -j ACCEPT >>> -A FORWARD -o tun+ -j ACCEPT >>> -A OUTPUT -o tun+ -j ACCEPT >>> >>> >>> >>>> finally, try running tcpdump/wireshark on yamaguchi and watch for >>>> packets coming in and going out. Do the ICMP packets arrive on >>>> yamaguchi's tun interface? >>>> >>>> >>>> >>> Tried that. I can see them going out of princeton: >>> >>> [root@princeton ~]# tcpdump -i tun0 icmp >>> tcpdump: WARNING: arptype 65534 not supported by libpcap - >>> >> falling back to >> >>> cooked socket >>> tcpdump: verbose output suppressed, use -v or -vv for full >>> >> protocol decode >> >>> listening on tun0, link-type LINUX_SLL (Linux cooked), >>> >> capture size 96 bytes >> >>> 07:26:13.622948 IP 192.168.5.1 > yamaguchi.denmantire.com: ICMP echo >>> request, id 31773, seq 1, length 64 >>> 07:26:14.622500 IP 192.168.5.1 > yamaguchi.denmantire.com: ICMP echo >>> request, id 31773, seq 2, length 64 >>> >>> ... but they never arrive in on yamaguchi: >>> >>> [root@yamaguchi sysconfig]# tcpdump -i tun0 icmp >>> tcpdump: WARNING: arptype 65534 not supported by libpcap - >>> >> falling back to >> >>> cooked socket >>> tcpdump: verbose output suppressed, use -v or -vv for full >>> >> protocol decode >> >>> listening on tun0, link-type LINUX_SLL (Linux cooked), >>> >> capture size 96 bytes >> >>> If, instead, I ping 192.168.5.6, both sides see it just fine: >>> >>> [root@princeton ~]# tcpdump -i tun0 icmp >>> tcpdump: WARNING: arptype 65534 not supported by libpcap - >>> >> falling back to >> >>> cooked socket >>> tcpdump: verbose output suppressed, use -v or -vv for full >>> >> protocol decode >> >>> listening on tun0, link-type LINUX_SLL (Linux cooked), >>> >> capture size 96 bytes >> >>> 07:30:04.402753 IP 192.168.5.1 > 192.168.5.6: ICMP echo >>> >> request, id 57630, >> >>> seq 1, length 64 >>> 07:30:04.474903 IP 192.168.5.6 > 192.168.5.1: ICMP echo >>> >> reply, id 57630, seq >> >>> 1, length 64 >>> >>> [root@yamaguchi sysconfig]# tcpdump -i tun0 icmp >>> tcpdump: WARNING: arptype 65534 not supported by libpcap - >>> >> falling back to >> >>> cooked socket >>> tcpdump: verbose output suppressed, use -v or -vv for full >>> >> protocol decode >> >>> listening on tun0, link-type LINUX_SLL (Linux cooked), >>> >> capture size 96 bytes >> >>> 07:30:04.434184 IP 192.168.5.1 > 192.168.5.6: ICMP echo >>> >> request, id 57630, >> >>> seq 1, length 64 >>> 07:30:04.434288 IP 192.168.5.6 > 192.168.5.1: ICMP echo >>> >> reply, id 57630, seq >> >>> 1, length 64 >>> 07:30:05.432302 IP 192.168.5.1 > 192.168.5.6: ICMP echo >>> >> request, id 57630, >> >>> seq 2, length 64 >>> 07:30:05.432379 IP 192.168.5.6 > 192.168.5.1: ICMP echo >>> >> reply, id 57630, seq >> >>> 2, length 64 >>> >>> >>> >>>>> But won't the tap interface give me bridging instead of routing? >>>>> >>>>> >>>>> >>>>> >>>>> >>>> nope. The 'tap' interface does IEE 802.3 encapsulation, >>>> >> i.e. you can >> >>>> pass non-IP traffic. The 'tun' interface does TCP/IP only. >>>> However, to >>>> do bridging the 'tap' interface is required (not vice versa). >>>> >>>> cheers, >>>> >>>> JJK >>>> >>>> >>>> >>> I may give the tap interface a try next - just out of desperation! >>> >>> Thanks much, >>> >>> -- tim -- >>> >>> >>> >>>> >>>> >>>>>> Hi Tim, >>>>>> >>>>>> can you verify that routing is enabled at both ends? >>>>>> cat /proc/sys/net/ipv4/ip_forward >>>>>> ? >>>>>> (0=disabled, 1=enabled) >>>>>> >>>>>> HTH, >>>>>> >>>>>> JJK >>>>>> >>>>>> Tim Boyer wrote: >>>>>> >>>>>> >>>>>> >>>>>>> I've bought the book, and the two sides are talking to each >>>>>>> >>>>>>> >>>>>>> >>>>>> other - kinda. >>>>>> >>>>>> >>>>>> >>>>>>> I'm afraid that I'm missing something conceptually here; >>>>>>> >>>>>>> >>>>>>> >>>>>> any help would be >>>>>> >>>>>> >>>>>> >>>>>>> appreciated. >>>>>>> >>>>>>> I'm running RHEL5.2 and OpenVPN 2.0.9 on both sides. I'm >>>>>>> >>>>>>> >>>>>>> >>>>>> taking it one step >>>>>> >>>>>> >>>>>> >>>>>>> at a time, so at this point I'm not worrying about subnets >>>>>>> >>>>>>> >>>>>>> >>>>>> on either side - >>>>>> >>>>>> >>>>>> >>>>>>> I just want to get them talking to each other. >>>>>>> >>>>>>> princeton is the server at 192.168.4.78, and yamaguchi >>>>>>> >>>>>>> >>>> the client at >>>> >>>> >>>>>>> 192.168.42.254. It's a nice simple server.conf: >>>>>>> >>>>>>> port 1194 >>>>>>> >>>>>>> proto udp >>>>>>> dev tun >>>>>>> ca ca.crt >>>>>>> cert princeton.crt >>>>>>> key princeton.key >>>>>>> >>>>>>> dh dh1024.pem >>>>>>> >>>>>>> server 192.168.5.0 255.255.255.0 >>>>>>> >>>>>>> ifconfig-pool-persist ipp.txt >>>>>>> >>>>>>> push "route 192.168.4.0 255.255.255.0" >>>>>>> >>>>>>> client-config-dir /etc/openvpn/ccd >>>>>>> route 192.168.42.0 255.255.255.0 >>>>>>> >>>>>>> keepalive 10 120 >>>>>>> >>>>>>> comp-lzo >>>>>>> >>>>>>> user nobody >>>>>>> group nobody >>>>>>> >>>>>>> persist-key >>>>>>> persist-tun >>>>>>> status openvpn-status.log >>>>>>> >>>>>>> verb 8 >>>>>>> mute 20 >>>>>>> >>>>>>> >>>>>>> and the file /etc/openvpn/ccd/yamaguchi contains >>>>>>> >>>>>>> iroute 192.168.42.0 255.255.255.0 >>>>>>> >>>>>>> So I can connect, and the .5.x routes work fine - >>>>>>> >>>>>>> >>>> yamaguchi can ping >>>> >>>> >>>>>>> princeton at 192.168.5.1, and princeton can ping yamaguchi >>>>>>> >>>>>>> >>>>>>> >>>>>> at 192.168.5.6. >>>>>> >>>>>> >>>>>> >>>>>>> So far, so good. >>>>>>> >>>>>>> Yamaguchi's added the .4.0 subnet to its routing table, and >>>>>>> >>>>>>> >>>>>>> >>>>>> can ping it just >>>>>> >>>>>> >>>>>> >>>>>>> fine: >>>>>>> >>>>>>> [root@yamaguchi network-scripts]# route >>>>>>> Kernel IP routing table >>>>>>> Destination Gateway Genmask Flags >>>>>>> >>>>>>> >>>>>>> >>>>>> Metric Ref Use >>>>>> >>>>>> >>>>>> >>>>>>> Iface >>>>>>> 192.168.5.1 192.168.5.5 255.255.255.255 UGH 0 >>>>>>> >>>>>>> >>>>>>> >>>>>> 0 0 tun0 >>>>>> >>>>>> >>>>>> >>>>>>> 192.168.5.5 * 255.255.255.255 UH 0 >>>>>>> >>>>>>> >>>>>>> >>>>>> 0 0 tun0 >>>>>> >>>>>> >>>>>> >>>>>>> 69.69.33.128 * 255.255.255.192 U 0 >>>>>>> >>>>>>> >>>>>>> >>>>>> 0 0 eth0 >>>>>> >>>>>> >>>>>> >>>>>>> 192.168.4.0 192.168.5.5 255.255.255.0 UG 0 >>>>>>> >>>>>>> >>>>>>> >>>>>> 0 0 tun0 >>>>>> >>>>>> >>>>>> >>>>>>> 192.168.42.0 * 255.255.255.0 U 0 >>>>>>> >>>>>>> >>>>>>> >>>>>> 0 0 eth1 >>>>>> >>>>>> >>>>>> >>>>>>> 169.254.0.0 * 255.255.0.0 U 0 >>>>>>> >>>>>>> >>>>>>> >>>>>> 0 0 eth1 >>>>>> >>>>>> >>>>>> >>>>>>> default 69.69.33.129 0.0.0.0 UG 0 >>>>>>> >>>>>>> >>>>>>> >>>>>> 0 0 eth0 >>>>>> >>>>>> >>>>>> >>>>>>> [root@yamaguchi network-scripts]# ping 192.168.4.78 >>>>>>> PING 192.168.4.78 (192.168.4.78) 56(84) bytes of data. >>>>>>> 64 bytes from 192.168.4.78: icmp_seq=1 ttl=64 time=71.6 ms >>>>>>> >>>>>>> Princeton's added the .42.0 subnet - but can't ping >>>>>>> >>>>>>> >>>>>>> >>>>>> yamaguchi at all: >>>>>> >>>>>> >>>>>> >>>>>>> [root@princeton ~]# route >>>>>>> Kernel IP routing table >>>>>>> Destination Gateway Genmask Flags >>>>>>> >>>>>>> >>>>>>> >>>>>> Metric Ref Use >>>>>> >>>>>> >>>>>> >>>>>>> Iface >>>>>>> 192.168.5.2 * 255.255.255.255 UH 0 >>>>>>> >>>>>>> >>>>>>> >>>>>> 0 0 tun0 >>>>>> >>>>>> >>>>>> >>>>>>> 192.168.5.0 192.168.5.2 255.255.255.0 UG 0 >>>>>>> >>>>>>> >>>>>>> >>>>>> 0 0 tun0 >>>>>> >>>>>> >>>>>> >>>>>>> 192.168.4.0 * 255.255.255.0 U 0 >>>>>>> >>>>>>> >>>>>>> >>>>>> 0 0 eth0 >>>>>> >>>>>> >>>>>> >>>>>>> 192.168.42.0 192.168.5.2 255.255.255.0 UG 0 >>>>>>> >>>>>>> >>>>>>> >>>>>> 0 0 tun0 >>>>>> >>>>>> >>>>>> >>>>>>> 169.254.0.0 * 255.255.0.0 U 0 >>>>>>> >>>>>>> >>>>>>> >>>>>> 0 0 eth0 >>>>>> >>>>>> >>>>>> >>>>>>> default saratoga4.denma 0.0.0.0 UG 0 >>>>>>> >>>>>>> >>>>>>> >>>>>> 0 0 eth0 >>>>>> >>>>>> >>>>>> >>>>>>> [root@princeton ~]# ping 192.168.42.254 >>>>>>> PING 192.168.42.254 (192.168.42.254) 56(84) bytes of data. >>>>>>> >>>>>>> --- 192.168.42.254 ping statistics --- >>>>>>> 17 packets transmitted, 0 received, 100% packet loss, >>>>>>> >> time 16000ms >> >>>>>>> tcpdump shows the packets trying to go out over tun0: >>>>>>> >>>>>>> [root@princeton network-scripts]# tcpdump -i tun0 icmp >>>>>>> tcpdump: WARNING: arptype 65534 not supported by libpcap - >>>>>>> >>>>>>> >>>>>>> >>>>>> falling back to >>>>>> >>>>>> >>>>>> >>>>>>> cooked socket >>>>>>> tcpdump: verbose output suppressed, use -v or -vv for full >>>>>>> >>>>>>> >>>>>>> >>>>>> protocol decode >>>>>> >>>>>> >>>>>> >>>>>>> listening on tun0, link-type LINUX_SLL (Linux cooked), >>>>>>> >>>>>>> >>>>>>> >>>>>> capture size 96 bytes >>>>>> >>>>>> >>>>>> >>>>>>> 17:13:03.605975 IP 192.168.5.1 > >>>>>>> >>>>>>> >>>> yamaguchi.denmantire.com: ICMP echo >>>> >>>> >>>>>>> request, id 48998, seq 17, length 64 >>>>>>> 17:13:04.606049 IP 192.168.5.1 > >>>>>>> >>>>>>> >>>> yamaguchi.denmantire.com: ICMP echo >>>> >>>> >>>>>>> request, id 48998, seq 18, length 64 >>>>>>> 17:13:05.606051 IP 192.168.5.1 > >>>>>>> >>>>>>> >>>> yamaguchi.denmantire.com: ICMP echo >>>> >>>> >>>>>>> request, id 48998, seq 19, length 64 >>>>>>> >>>>>>> but I never see anything getting to the other side. >>>>>>> >>>>>>> It's not a firewall issue (I think...) because princeton >>>>>>> >>>>>>> >>>>>>> >>>>>> can ping 5.6 just >>>>>> >>>>>> >>>>>> >>>>>>> fine, also going through the tun0 interface. >>>>>>> >>>>>>> Which means I'm probably missing something blindingly >>>>>>> >>>>>>> >>>>>>> >>>>>> obvious. Pointers, >>>>>> >>>>>> >>>>>> >>>>>>> suggestions, and whaps upside the head with a 2x4 for >>>>>>> >>>>>>> >>>>>>> >>>>>> missing something >>>>>> >>>>>> >>>>>> >>>>>>> blindingly obvious greatfully accepted... >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> |
