|
|
Hi，James Yonan >Okay, if I understand you correctly you are saying that you can ping _through_ >192.168.201.2 to another machine but you cannot ping it directly. 192.168.201.2 is one subnet box(A), it only connects with the linux gateway box(B). And, the gateway ip is 192.168.201.1, its external ip is 10.1.0.232, another subnet. My client windowsXP box(10.1.0.176) in the 10.1.0.0/23 subnet. >And the "RRRRR" received on 192.168.201.2 when you try to ping it directly >indicates that OpenVPN is receiving the ping packets via the tunnel, but they >are not getting echoed back. >Are you sure you have "iptables -A INPUT" rules as well as "iptables -A >FORWARD" rules for the tap dev? yes, my firewall rules as follow: /etc/rc.local, my orig firwall rules echo 1 > /proc/sys/net/ipv4/ip_forward iptables -F INPUT iptables -F FORWARD iptables -F POSTROUTING -t nat iptables -P FORWARD DROP iptables -A FORWARD -s 192.168.201.0/24 -j ACCEPT iptables -t nat -A POSTROUTING -o eth0 -s 192.168.201.0/24 -j SNAT --to 10.1.0.232 iptables -A FORWARD -d 192.168.201.0/24 -j ACCEPT firewall.sh (eth0 is the external ip, eth1 is the internal ip) #!/bin/bash PRIVATE=192.168.201.0/24 LOOP=127.0.0.1 iptables -A INPUT -i eth0 -s $LOOP -j DROP iptables -A FORWARD -i eth0 -s $LOOP -j DROP iptables -A INPUT -i eth0 -d $LOOP -j DROP iptables -A FORWARD -i eth0 -d $LOOP -j DROP iptables -A FORWARD -p tcp --sport 137:139 -o eth0 -j DROP iptables -A FORWARD -p udp --sport 137:139 -o eth0 -j DROP iptables -A OUTPUT -p tcp --sport 137:139 -o eth0 -j DROP iptables -A OUTPUT -p udp --sport 137:139 -o eth0 -j DROP iptables -A FORWARD -s ! $PRIVATE -i eth1 -j DROP iptables -A INPUT -s $LOOP -j ACCEPT iptables -A INPUT -d $LOOP -j ACCEPT iptables -A INPUT -p icmp --icmp-type echo-request -j ACCEPT iptables -A INPUT -p udp --dport 5000 -j ACCEPT iptables -A INPUT -i tap+ -j ACCEPT iptables -A FORWARD -i tap+ -j ACCEPT iptables -A INPUT -i eth1 -j ACCEPT iptables -A FORWARD -i eth1 -j ACCEPT iptables -A OUTPUT -m state --state NEW -o eth0 -j ACCEPT iptables -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT iptables -A FORWARD -m state --state NEW -o eth0 -j ACCEPT iptables -A FORWARD -m state --state ESTABLISHED,RELATED -j ACCEPT iptables -t nat -A POSTROUTING -s $PRIVATE -o eth0 -j MASQUERADE >You might also try "tcpdump -i tap[n]" on 192.168.201.2 to see how far the >ping packets are getting before they are dropped. I run tcpdump on the linux gateway box: When I ping 192.168.201.2 from my xp box, it shows: # tcpdump -s 1518 -lennx -i tap0 host 192.168.201.2 and host 192.168.1.2 | tcpshow -cooked tcpdump: listening on tap0 --------------------------------------------------------------------------- Packet 1 TIME: 09:00:48.145804 ARP: 192.168.1.2 (00:FF:1E:2E:93:84) asks where is 192.168.201.2 --------------------------------------------------------------------------- Packet 2 TIME: 09:00:53.635070 (5.489266) ARP: 192.168.1.2 (00:FF:1E:2E:93:84) asks where is 192.168.201.2 --------------------------------------------------------------------------- Packet 3 TIME: 09:00:59.134926 (5.499856) ARP: 192.168.1.2 (00:FF:1E:2E:93:84) asks where is 192.168.201.2 --------------------------------------------------------------------------- And the openvpn client shows: WWWWWW the openvpn server side shows: RRRRRR >Also, since you are not bridging, make sure on the linux side that the tap >subnet is totally distinct from the local ethernet subnet. Yes, the 192.168.201.2 box is connected with the 192.168.201.1 directly. Best Regards Ouyang Kai > >oyk <oyk@xxxxxxxxxxx> said: > >> Hi，James Yonan >> Thank your help. >> Today, I am in the lab, so I test the openvpn between two subnetworks. >> The client side is a WindowsXP box, and the server side is a linux box, >which is another subnetwork's gateway. >> 192.168.201.2(linux boxB) -- 192.1.68.201.1 && 10.1.0.232 (linux >boxA)------- 10.1.0.176(windows xp) >> On the xp box, >> remote 10.1.0.232 >> dev tap >> dev-node my-tap >> secret key.txt >> ping 10 >> verb 5 >> >> myroute.bat >> route add 192.168.201.0 mask 255.255.255.0 192.168.1.2 >> >> On the linux boxA, >> remote 10.1.1.176 >> dev tap >> up ./tap.up >> secret key.txt >> verb 5 >> >> and the tap.up: >> #!/bin/bash >> ifconfig $1 192.168.1.1 netmask 255.255.255.0 mtu $2 >> >> About the iptables: >> I write the firewall rules based on sample-config-files/firewall.sh. I >can ping from 192.168.201.2 to the >> network 10.1.0.0/23. From my xp box, I can ping 192.168.201.1, but I can not >ping the 192.168.201.2 box. >> When I ping 192.168.1.1 or 192.168.201.1 from 10.1.0.176, both sides show >RWRW..... >> When I ping 192.168.201.2 from 10.1.0.176, the client side shows >WWWW...., and the server side shows RRRRR.... >> What's problem about my configuration? If it is the filewall rule >problem, why can I ping 192.168.201.1? >> >> Thank you! >> Best Regards >> Ouyang Kai >> >Ouyang, >> > >> >You have some errors in your configuration. You should try to follow one of >> >the Windows <-> Linux examples in the Windows README as closely as possible, >> >as these examples are known to work. >> > >> >First of all you, you have --dev tap on one end and --dev tun on the other. >> >This alone will kill the tunnel. If Windows is involved in the link, you need >> >to have --dev tap on each side of the connection, at least until a tun device >> >is implemented for Windows (which hasn't happened yet). >> > >> >On windows you set the TAP-Win32 adapter IP address using either the network >> >control panel or the netssh command. This is discussed in the OpenVPN Windows >> >README: >> > >> >http://openvpn.sourceforge.net/install32.html >> > >> >On FreeBSD you need to have an --up script as well to configure the tap device >> >(The --ifconfig option on OpenVPN is just a helper for the ifconfig command -- >> >but it does not do TAP devices yet). You need to adapt the --up script used >> >in the README from Linux to FreeBSD. The conversion is really just making >> >sure the format of the ifconfig command is correct for FreeBSD (annoyingly, >> >ifconfig tends to have to have small incompatibilities across different OSes). >> > >> >Once you get this worked out, run with --verb 5 on each side and you will get >> >'R' and 'W' chars output for each packet read and written. If you get 'R' >> >chars on each end of the connection, it means that both sides are actually >> >talking to each other. >> > >> >James >> > >> >> >> >> > > > >-- > > > > > > > >------------------------------------------------------- >This SF.Net email sponsored by: Free pre-built ASP.NET sites including >Data Reports, E-commerce, Portals, and Forums are available now. >Download today and enter to win an XBOX or Visual Studio .NET. >http://aspnet.click-url.com/go/psa00100003ave/direct;at.aspnet_072303_01/01 >_______________________________________________ >Openvpn-users mailing list >Openvpn-users@xxxxxxxxxxxxxxxxxxxxx >https://lists.sourceforge.net/lists/listinfo/openvpn-users > >. |