On Wed, Oct 28, 2009 at 06:24:05AM -0300, Daniel Bareiro wrote: > > Hi all! > > I was making a first attempt to establish a VPN between my house and the > office. The scenery from the side of my house is the following one: > ________ > +----------+ +-----------+ +----------+ ____/ \___ > | OpenVPN |_____| GNU/Linux |_____| ADSL |_____/ Internet \ > | server | | Firewall | | Router | \____ ____/ > +----------+ +-----------+ +----------+ \_______/ > > Local network: 10.1.0.0/24 > VPN network: 10.8.0.0/24 any particular reason not to run the vpn server on the firewall ! it is already the default gw for your local lan and it would make routing easier. what you have below is the a sympton of the routing problem. also any reason you choose tun over tap - I usually default to tap. Alex > > In the GNU/Linux firewall configuration (using Shorewall), I only added a > DNAT rule to the OpenVPN server. I believe that it is the unique thing that > it would be being necessary. > > Besides this, in router I added a rule doing forwarding of the > originating traffic of its own WAN with port 1194 to the interface that > it has in the other end that it gives with GNU/Linux firewall. > > Until this instance, starting a OpenVPN client in the office I could > verify that the tunnel is established, but I can only reach the OpenVPN > server. The rest of hosts of my LAN is unareachables. > > The following one is a capture with tcpump in the OpenVPN server when I > doing ping from the office to one host of my house: > > # tcpdump -i tun0 > 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:08:17.231084 IP 10.8.0.6 > ns1.freesoftware.org: ICMP echo request, id 47698, seq 1, length 64 > 07:08:18.233021 IP 10.8.0.6 > ns1.freesoftware.org: ICMP echo request, id 47698, seq 2, length 64 > 07:08:19.231793 IP 10.8.0.6 > ns1.freesoftware.org: ICMP echo request, id 47698, seq 3, length 64 > > Apparently it would be lacking some way that causes that the packages > could return. > > Then I tried adding the following thing: > > * To add in my GNU/Linux firewall a rule so that all the traffic that > goes to the network 10.8.0.0/24 is reached through the IP of the > OpenVPN server: > > # route add -net 10.8.0.0 netmask 255.255.255.0 gw 10.1.0.4 > > * Enable forwarding in the OpenVPN server: > > # echo 1 > /proc/sys/net/ipv4/ip_forward > > And I repeated the test: > > 07:13:17.213590 IP 10.8.0.6 > ns1.freesoftware.org: ICMP echo request, id 55380, seq 1, length 64 > 07:13:17.213942 IP ns1.freesoftware.org > 10.8.0.6: ICMP echo reply, id 55380, seq 1, length 64 > 07:13:18.215097 IP 10.8.0.6 > ns1.freesoftware.org: ICMP echo request, id 55380, seq 2, length 64 > 07:13:18.215433 IP ns1.freesoftware.org > 10.8.0.6: ICMP echo reply, id 55380, seq 2, length 64 > 07:13:19.215920 IP 10.8.0.6 > ns1.freesoftware.org: ICMP echo request, id 55380, seq 3, length 64 > 07:13:19.216272 IP ns1.freesoftware.org > 10.8.0.6: ICMP echo reply, id 55380, seq 3, length 64 > > This way already I could reach with ping/nmap at the other hosts from the > network. But in tests that I was doing there are moments at which when > trying to login using ssh I can get it and in others I cannot. In this > second case, tcpdump showed a similar problem to which commented above. > > I have the impression that continues existing some routing problem > somewhere. Some idea of what can be the problem? > > Thanks in advance for your reply. > > Regards, > Daniel -- "We've had no evidence that Saddam Hussein was involved in Sept. 11." - George W. Bush 08/17/2003 Washington, DC
Attachment:
signature.asc
Description: Digital signature