Hi JJK--
On 05/04/2015 12:41 PM, Jan Just Keijser wrote:
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
Jan Just Keijser, thanks. You pointed out something I had not seen.
I will do the diagram tonight when I hope to have a bit more time.
For now, it looks like one thing I need to do is to remove the routing
directive in the *client* that refers to 192.168.0.0/24. Do you agree?
The client normally resides in a 192.168.1.0/24 lan.
Thanks, 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
