|
|
Date: Sun, 09 Sep 2007 18:35:20 -0700 From: "Daniel L. Miller" <dmiller@xxxxxxxxx> Subject: Re: [Openvpn-users] Possible routing problem To: openvpn-users@xxxxxxxxxxxxxxxxxxxxx Message-ID: <46E49F58.7080504@xxxxxxxxx> Content-Type: text/plain; charset=ISO-8859-1; format=flowed john@xxxxxxxxx wrote: > I recently set up openvpn between two lans and wanted clients on both sides > to have full access to either side.... > Thanks for the reply. My openvpn server config follows - I think it's fairly straightforward: server 172.27.0.0 255.255.0.0 tls-server local 192.168.0.222 port 1195 proto udp dev tun ca /etc/openvpn/easy-rsa/keys/ca.crt cert /etc/openvpn/easy-rsa/keys/server.crt key /etc/openvpn/easy-rsa/keys/server.key # This file should be kept secret dh /etc/openvpn/easy-rsa/keys/dh1024.pem tls-auth /etc/openvpn/easy-rsa/keys/ta.key 0 keepalive 10 120 persist-key ifconfig-pool-persist /etc/openvpn/customers-ip.txt client-config-dir /etc/openvpn/ccd status customers.log log-append /var/log/openvpn-customers.log verb 3 replay-window 72 30 comp-lzo # route to a remote lan on a client route 10.4.1.0 255.255.255.0 Then the server's routing table: 172.27.0.2 dev tun0 proto kernel scope link src 172.27.0.1 192.168.20.0/24 dev vmnet8 proto kernel scope link src 192.168.20.1 10.4.1.0/24 via 172.27.0.2 dev tun0 192.168.0.0/24 dev eth0 proto kernel scope link src 192.168.0.71 192.168.0.0/24 dev br1 proto kernel scope link src 192.168.0.72 192.168.30.0/24 dev vmnet1 proto kernel scope link src 192.168.30.1 172.27.0.0/16 via 172.27.0.2 dev tun0 default via 192.168.0.1 dev eth0 VPN clients and the VPN server communicate without any problem. I can see the routes for the tun interface on the server - everything looks right to me. On a server-side LAN client, I add a route to the VPN. For a Windows client, I would execute: route add 172.27.0.0 mask 255.255.0.0 192.168.0.71 And then test the connection. I can ping the VPN server at 172.27.0.1 without problem. But I can't ping the VPN clients. Is an iptables rule required for this step? Daniel ----------------------- Daniel, I'm a little confused with your setup... The server directive should be a non-routable, shouldn't it? i.e., I have server 10.0.2.0 255.255.255.0 dev tun topology subnet I don't worry about local setting, it's optional and will bind to all the internal ethernet cards on the network. by setting the topology to subnet and using the ifconfig-pool-persist directive, the other ends get a consistent address within the 10.0.2.0/24 network. In ther words, the server end of the tunnel gets 10.0.2.1 and the client consistently gets 10.0.2.4 (in my case). I then push, from the server, the internal routes of the server, i.e., push route "192.168.xx1.0 255.255.255.0" push route "192.168.xx2.0 255.255.255.0" etc (I'm pushing 4 routes) and added client-to-client and persist-key persist-tun My client end is route 192.168.x10.0 255.255.255.0 the above statement being part of server config, I just needed to add the route manually to the client's internal network. Note that my client is actually a single server with workstations behind it getting their dhcp addresses from the local server, 192.168.x10.1, I am not serving dhcp from the server. The client "server" gets it's server routes pushed to it and this is transparent to all the workstations on the client end. I add no routes to the client's workstations since they only have one route now. The client is the only gateway for the client's lan. So, my server tun0 is 10.0.2.1 my client "server" tun0 is 10.0.2.4 The OpenVPN client end is setup by the OpenVPN server, but at the server I had to add the route to the client, i.e, #route add -net 192.168.x10.0/24 gw 10.0.2.4 (the client end of the tunnel) Setting the topology to subnet simplified this greatly, I'm only dealing with two addresses, 10.0.2.1 and 10.0.2.4, either end of the tunnel. The server needs the addition of the route to the client's network, the client gets the route from the server ( as I mentioned, I have linux boxes at either end, so I just popped the route add -net statemet into the openvpn startup script, as well as the proxy_arp statements, echo 1 > /proc/sys/net etc). As for the firewalls, the server has a static ip, the client is on a cable network, so on the server I have iptables -I INPUT -i eth0 -p udp -s my.dyndns.addr --sport 1194 --dport 1194 -j ACCEPT iptables -I OUTPUT -o eth0 -p udp -s my.dyndns.addr --sport 1194 --dport 1194 -j ACCEPT iptables -I FORWARD -i eth0 -p udp -s my.dyndns.addr --sport 1194 --dport 1194 -j ACCEPT (This last one probably isn't needed) iptables -I INPUT -i tun+ -s 192.168.x10.0/24 -d 192.168.xx1.0/24 -j ACCEPT iptables -I OUTPUT -o tun+ -s 192.168.xx1.0/24 -d 192.168.10.0/24 -j ACCEPT iptables -I FORWARD -i tun+ -s 192.168.x10.0/24 -d 192.168.xx1.0/24 -j ACCEPT iptables -I FORWARD -o tun+ -s 192.168.xx1.0/24 -d 192.168.x10.0/24 -j ACCEPT iptables -I INPUT -i tun+ -s 10.0.2.4 -d 192.168.xx1.0/24 -j ACCEPT iptables -I OUTPUT -o tun+ -s 10.0.2.4 -d 192.168.x10.0/24 -j ACCEPT iptables -I FORWARD -i tun+ -s 10.0.2.4 -d 192.168.xx1.0/24 -j ACCEPT iptables -I FORWARD -o tun+ -s 10.0.2.4 -d 192.168.x10.0/24 -j ACCEPT iptables -A INPUT -i tun+ -j ACCEPT iptables -A OUTPUT -o tun+ -j ACCEPT iptables -A FORWARD -i tun+ -j ACCEPT Now, for those others who are reading this, I know it's overkill, but I have not finished cleaning this up and getting rid of the unnecesary stuff. I suspect that the -s 10. network stuff really isn't needed, but I don't think it can hurt right now. I was strugging with the server side of the firewall and the middle eight statements seemed to help. On the client side all I have is the initial three iptables statements with the server's static ip address as well as the last 3 statements. Hopefully that will get you closer, Daniel, and hopefully it's not too disjointed an explanation... it's getting late for a Sunday and I'm hitting the rack. The default client and server .conf files and their in-line comments helped me a lot, and I really appreciated the fact that they were part of the distribution. I had been struggling with openswan/ipsec and intermittent connectivity for weeks. OpenVPN is far easier to set up and it consistently works well. Regards, John C. ____________________________________________ Openvpn-users mailing list Openvpn-users@xxxxxxxxxxxxxxxxxxxxx https://lists.sourceforge.net/lists/listinfo/openvpn-users |