Hi Douglas, Douglas D Germann Sr wrote: > On 05/01/2015 04:48 AM, Jan Just Keijser wrote: >> Hi Douglas, >> >> On 01/05/15 05:06, Douglas D Germann Sr wrote: >>> Friends-- >>> >>> My first post, and by reading this you will see how new I am to >>> openvpn. So please be gentle. <grin> >>> >>> I have one vpn set up and trying to get a second vpn set up. The two >>> seem to be conflicting with each other. There is so far only one >>> client machine, but we will be adding another in a few days. >>> >>> The problem: Each of the VPNs connect with the client. That's good. >>> But when I have them both running, I cannot ping nor ssh to the >>> client from machines on the server's lan. I want to be able to ssh >>> to the client so I can perform maintenance on that machine. (I will >>> soon add another remote machine and need to do the same on it.) I am >>> thinking that my routing commands may be conflicting with one another. >>> >>> Production environment. Both servers at the same physical location. >>> Server1: earth, running Ubuntu 12.04 lts; local address 192.168.0.201 >>> Server2: mariah, on Synology ds 513 j nas; local address 192.168.0.202 >>> >>> Client: air, at a remote location. >>> >>> (Not sure if testing is a problem, since for trouble shooting this, >>> I have the client machine physically in the same building behind the >>> same router as the two servers. Client's address for now is >>> 192.168.0.211, although normally it is at 192.168.1.16 at the remote >>> location.) >>> >>> (((((tun0))))) >>> >>> This tunnel has been running reliably for 18 months or so. >>> >>> Server1/earth server.conf: >>> =============== >>> port 1194 >>> proto udp >>> dev tun >>> >>> ca /etc/openvpn/ca.crt >>> cert /etc/openvpn/earth.crt >>> key /etc/openvpn/earth.key # This file should be kept secret >>> dh /etc/openvpn/dh1024.pem >>> >>> server 10.8.0.0 255.255.255.0 >>> ifconfig-pool-persist ipp.txt >>> >>> client-config-dir /etc/openvpn/ccd >>> route 192.168.1.0 255.255.255.0 >>> client-to-client >>> keepalive 10 120 >>> >>> comp-lzo >>> max-clients 2 >>> persist-key >>> persist-tun >>> >>> status openvpn-status.log >>> verb 3 >>> ###########added 20150426 >>> push “route 10.8.0.0 255.255.255.0” >>> push “route 192.168.1.0 255.255.255.0” >>> ================ >>> >>> Its ccd/air file reads: >>> ========== >>> iroute 192.168.1.0 255.255.255.0 >>> ifconfig-push 10.8.0.42 10.8.0.41 >>> ========== >>> >>> client/air's client.conf for this connection: >>> =============== >>> client >>> dev tun >>> proto udp >>> remote [blanked] 1194 >>> resolv-retry infinite >>> nobind >>> persist-key >>> persist-tun >>> ca /etc/openvpn/ca.crt >>> cert /etc/openvpn/air.crt >>> key /etc/openvpn/air.key >>> remote-cert-tls server >>> comp-lzo >>> verb 3 >>> ================ >>> >>> >>> (((((tun1))))) >>> >>> This is the new tunnel. Client has been able to connect and access >>> and edit files on mariah, but I cannot ssh into the client using >>> this vpn. >>> >>> server2/mariah's server.conf: >>> ================= >>> push "route 10.8.1.0 255.255.255.0" >>> >>> route 192.168.1.0 255.255.255.0 >>> route 10.8.1.0 255.255.255.0 >>> client-config-dir /usr/syno/etc/packages/VPNCenter/openvpn/ccd >>> >>> dev tun >>> management 127.0.0.1 1195 >>> server 10.8.1.0 255.255.255.0 >>> >>> dh /usr/syno/etc/packages/VPNCenter/openvpn/dh2048.pem >>> ca /usr/syno/etc/packages/VPNCenter/openvpn/ca.crt >>> cert /usr/syno/etc/packages/VPNCenter/openvpn/server.crt >>> key /usr/syno/etc/packages/VPNCenter/openvpn/server.key >>> max-clients 3 >>> >>> comp-lzo >>> >>> persist-tun >>> persist-key >>> >>> verb 3 >>> log-append /var/log/openvpn.log >>> keepalive 10 60 >>> reneg-sec 0 >>> >>> status-version 2 >>> proto udp6 >>> port [blanked] >>> >>> user nobody >>> group nobody >>> =============== >>> >>> Its ccd/air2 file reads: >>> ======= >>> iroute 192.168.1.0 255.255.255.0 >>> ifconfig-push 10.8.1.6 10.8.1.5 >>> ======= >>> >>> client/air's client.conf file for this connection reads: >>> =========== >>> client >>> dev tun1 >>> proto udp >>> remote [blanked] >>> #remote 192.168.0.201 >>> resolv-retry infinite >>> nobind >>> persist-key >>> persist-tun >>> dh dh2048.pem >>> ca /etc/openvpn/synca.crt >>> cert /etc/openvpn/air2.crt >>> key /etc/openvpn/air2.key >>> remote-cert-tls server >>> comp-lzo >>> verb 3 >>> =========== >>> >>> The router behind which the two servers live has these static routes: >>> >>> 10.8.0.1 255.255.255.255 gw192.168.0.201 >>> 192.168.1.0 255.255.255.0 gw192.168.0.201 >>> 10.8.0.0 255.255.255.0 gw192.168.0.201 >>> 10.8.1.1 255.255.255.255 gw192.168.0.202 >>> 10.8.1.0 255.255.255.0 gw192.168.0.202 >>> And the ports are forwarded 1194 to internal 1194 on 192.168.0.201 >>> (UDP) and the correct port on 192.168.0.202 (ALL). >>> >>> Besides the routing commands, I am wondering whether these two >>> things might be issues: >>> >>> 1. The ccd file on server2/mariah is named air2. Ought it be named air? >>> 2. The air2.crt file on the client (air) has a couple of entries >>> that say CN=[address of the dynamic dns I am using], but not air nor >>> air2. Ought I edit this or recreate the keys? >>> >>> So: how do I get both of these working and playing well together? >>> >> >> the name of a CCD file is very important - it needs to match the >> exact name of the CN=.... part of the client-side certificate. An >> easy way to verify whether the server picks up the CCD file is by >> adding the option >> ccd-exclusive >> to the server config and restart it - if the client is no longer able >> to connect then you're not using the right name. >> >> Whether it's a routing issue or not is hard to tell - things look OK >> at first sight, but it is much more important to see the routing >> tables on both the OpenVPN server and client after the VPN has come >> up. Is it possible for you to get those? >> >> HTH, >> >> JJK >> > @Jan Just Keijser-- > > Thank you very much for helping me! I have been having a hard time > getting this to work. You are giving me hope! > > I changed the ccd file name to match the CN= line, but left off the > part that said "/name=OpenVPN/emailAddress=root@localhost" and then > restarted the server and the client. Connection went well. But still > cannot ping nor ssh into the client (air) at 10.8.1.6 from a client on > the 192.168.0.0 lan. Server can however ping 10.8.1.6. > > At this point the route command on the server gives: > ===== > mariah> route > Kernel IP routing table > Destination Gateway Genmask Flags Metric Ref Use Iface > default 192.168.0.1 0.0.0.0 UG 0 0 0 eth0 > 10.8.1.0 10.8.1.2 255.255.255.0 UG 0 0 0 tun0 > 10.8.1.2 * 255.255.255.255 UH 0 0 0 tun0 > 192.168.0.0 * 255.255.255.0 U 0 0 0 eth0 > 192.168.1.0 10.8.1.2 255.255.255.0 UG 0 0 0 tun0 > mariah> > ===== > > The route command on the client gives: > ===== > doug@air:~$ route > Kernel IP routing table > Destination Gateway Genmask Flags Metric Ref Use Iface > default 192.168.0.1 0.0.0.0 UG 0 0 0 eth0 > 10.8.1.0 10.8.1.5 255.255.255.0 UG 0 0 0 tun1 > 10.8.1.1 10.8.1.5 255.255.255.255 UGH 0 0 0 tun1 > 10.8.1.5 * 255.255.255.255 UH 0 0 0 tun1 > link-local * 255.255.0.0 U 1000 0 0 eth0 > 192.168.0.0 * 255.255.255.0 U 1 0 0 eth0 > doug@air:~$ > ===== > > So next I added a line in the server.conf file on the server, to read: > ccd-exclusive > And then restarted first server, then client. The shutdown on the > client hung and I had to do a hard reboot. (Usually when it hangs on > reboot there is some issue with networking, but I don't know which > logs to check.) Client came up OK after the hard reboot. They appear > to be connected. > > The server route command now yields: > ===== > mariah> route > Kernel IP routing table > Destination Gateway Genmask Flags Metric Ref Use Iface > default 192.168.0.1 0.0.0.0 UG 0 0 0 eth0 > 10.8.1.0 10.8.1.2 255.255.255.0 UG 0 0 0 tun0 > 10.8.1.2 * 255.255.255.255 UH 0 0 0 tun0 > 192.168.0.0 * 255.255.255.0 U 0 0 0 eth0 > 192.168.1.0 10.8.1.2 255.255.255.0 UG 0 0 0 tun0 > mariah> > ===== > > That looks unchanged to me. > > The client route command now yields: > ===== > doug@air:~$ route > Kernel IP routing table > Destination Gateway Genmask Flags Metric Ref Use Iface > default 192.168.0.1 0.0.0.0 UG 0 0 0 eth0 > 10.8.1.0 10.8.1.5 255.255.255.0 UG 0 0 0 tun1 > 10.8.1.1 10.8.1.5 255.255.255.255 UGH 0 0 0 tun1 > 10.8.1.5 * 255.255.255.255 UH 0 0 0 tun1 > link-local * 255.255.0.0 U 1000 0 0 eth0 > 192.168.0.0 * 255.255.255.0 U 1 0 0 eth0 > doug@air:~$ > ===== > > Which also looks unchanged to me. So it looks like I am using the > right name for the ccd file, yes? > > I am wondering if these routing lines are an issue (right now, I am > not running tun0 on the client air): > tun0 server.conf: route 192.168.1.0 255.255.255.0 > tun1 server.conf: route 192.168.1.0 255.255.255.0 > > Also, tun1 server.conf has no push directives, but tun0 server.conf > has: push “route 192.168.1.0 255.255.255.0” > > So the question still remains, how can I ssh into the tun1 client > (10.8.0.6) from a machine in the 192.168.0.0 lan? > > I am adding another client machine, and will have to create new keys > for that client. Would it make sense for me to re-create the keys for > the mariah server and the air client? Could there be an issue there? > Seems to me unlikely given that they connect, but the unexpected CN in > the server.crt file makes me wonder.
this is definitely a routing issue. your server and client routines tables both show 192.168.0.0 * 255.255.255.0 U 0 0 0 eth0 that means both sides "think" the 192.168/24 subnet is reachable on their end; contacting a host on this LAN from the remote side will thus never work. Draw a diagram for yourself with all the network interfaces and subnets involved in your VPN setup. It is simplest to keep each subnet unique, e.g. 192.168.1/24 - eth0 | SERVER | tun1 - 10.8.0.1/16 ------------- 10.8.0.5/16 - tun0 | CLIENT air | 192.168.0./24 etc. HTH, JJK ------------------------------------------------------------------------------ One dashboard for servers and applications across Physical-Virtual-Cloud Widest out-of-the-box monitoring support with 50+ applications Performance metrics, stats and reports that give you Actionable Insights Deep dive visibility with transaction tracing using APM Insight. http://ad.doubleclick.net/ddm/clk/290420510;117567292;y _______________________________________________ Openvpn-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/openvpn-users
