JJK--
On 05/05/2015 01:59 PM, Jan Just Keijser wrote:
Hi Douglas,
On 05/05/15 04:58, Douglas D Germann Sr wrote:
On 05/04/2015 02:47 PM, Jan Just Keijser wrote:
On 04/05/15 18:57, Douglas D Germann Sr wrote:
On 05/04/2015 12:41 PM, Jan Just Keijser wrote:
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.
that would be a good start, but the routing diagram will certainly
help you pinpoint other problems.
Also, try ssh'ing/pinging other hosts first, e.g. from a VPN client
try to reach the LAN address of the VPN server and vice versa.
Is IP forwarding enabled on the client?
JJK
Hi, JJK--
ip forwarding is enabled on the client (air):
=====
doug@air:~$ sysctl net.ipv4.ip_forward
net.ipv4.ip_forward = 1
=====
From client/air: can ping tun1 server (mariah). Not sure that is
helpful, because the client is on the same lan, currently. Can also
ping the tun0 server, to which air is not currently connected via
vpn. Can also ping other hosts on 192.168.0.0/24.
From tun1 server (mariah): can ping client (air) at 192.168.0.212 and
10.8.1.6. Can ping other stations on 192.168.0.0/24.
OK, I have looked in the server's (mariah) server.conf and ccd
directory and find no directives referring to 192.168.0.0 lan; there
is a reference to 192.168.1.0. Likewise, no references in the client
openvpn.conf files to either of these lans. There is the remote
[dyndns] [port] command which is forwarded by the router to
192.168.0.202 (mariah). And here I thought I was on to something! So
how do both machines end up pointing to 192.168.0.0/24? Maybe because
they are both behind the same router?
Maybe I have found a clue: at some point on tun0 server (earth) I did
*
/sbin/route add -net 192.168.0.0 netmask 255.255.255.0 gw 10.8.0.41
I am not sure, but it seems the command to reverse this would be
/sbin/route del -net [same rest of command]. Ought I try that? I am
nervous to try something I am unclear about. Then again, this is the
tun0 server, and the tun1 routing is at issue.
Maybe the reason both routing tables point to 192.168.0.0 is that
both are behind the router serving up that lan, and this is really a
non issue.
So here is my first attempt at a diagram. Not sure if it has enough info:
lan side:
=====
router 192.168.0.1
--tun0 server earth .201 eth0 10.8.0.1
--tun1 server mariah .202 eth0 10.8.1.1
--6 other hosts (none have more than one eth card)
--2 printers
--smart television
--several iphones, kindles, etc.
vpn clients:
=======
air eth0
--tun0 10.8.0.42
--tun1 10.8.1.6
--lan 192.168.1.16 (its usual home)
--lan 192.168.0.212 (where it is now)
wind eth0
--to be assigned (I am just ready to create a client.conf file and
create the keys) It will be assigned to the tun1 server mariah.
I don't know how to compute the /16 parts you mentioned. Maybe those
are just a given for 10.x.x.x nets.
So are we making any progress? Hopefully you are seeing some clues.
actually, some parts of your setup are very hard to debug with the
client sitting in the same network/subnet as the server. It might be
useful to put the client really in a separate network, if your routing
equipment can handle that.
Your network diagrams look OK, can you ping the tun1 interface of the
client from the server and vice versa?
JJK
JJK--
Thanks!
If I put another router behind (downstream of) this router, and gave it
say 192.168.2.x/24, would that give us the ability to debug properly? By
that I mean that I plug the new router into the present router, and then
the client (air) into the new router.
From server (mariah) I can ping 10.8.1.6. From client (air) I can ping
10.8.1.1.
Thanks for helping me, 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
