Menu
▾
▴
Re: [Openvpn-users] Server can't ping client
|
From: Tim B. <ti...@de...> - 2008-09-03 02:47:27
|
> > 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? > > cheers, > > JJK > 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. -- tim -- > > 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... > >>>>> > >>>>> > >>>>> > >>>>> |