Don't see the network behind the openvpn server?

Everything seems configured correctly but I can't see the network behind the openvpn server. What's the matter tell me?
The network behind the server: 10.15.17.0
Although the server 10.15.17.1 visible.
But 10.15.17.2 and so on anymore.

And another problem when I want to route 10.15.17.0 to give the current one to the client
Server config push route removed "10.15.17.0 255.255.255.0"

And added 10.15.17.0 255.255.255.0 iroute in the client file in the ccd and ping 10.15.17.1 can't

Client network:
192.168.0.0
192.168.1.0

server.conf

port 1194
proto udp
dev tun
ca ca.crt
cert server.crt
key server.key
dh dh.pem
topology subnet
server 10.8.0.0 255.255.255.0
ifconfig-pool-persist /var/log/openvpn/ipp.txt
## transfer routes to the clients (network for example)
## you can pass all at once, or selectively in the file ccd/clientX
push "route 192.168.0.0 255.255.255.0"
push "route 192.168.1.0 255.255.255.0"
push "route 10.15.17.0 255.255.255.0"
;push "redirect-gateway def1 bypass-dhcp"
;push "dhcp-option DNS 208.67.222.222"
;push "dhcp-option DNS 208.67.220.220"
client-config-dir ccd
## routing for the server if need be
route 192.168.0.0 255.255.255.0
route 192.168.1.0 255.255.255.0
route-gateway 10.8.0.1
client-to-client
keepalive 10 120
tls-auth ta.key 0
cipher AES-128-CBC
auth SHA1
comp-lzo
persist-key
persist-tun
status /var/log/openvpn/openvpn-status.log
log /var/log/openvpn/openvpn.log
log-append /var/log/openvpn/openvpn.log
verb 3
explicit-exit-notify 1
524288 sndbuf
rcvbuf 524288
push "sndbuf 524288"
push "rcvbuf 524288"


сcd clinet
/etc/openvpn/ccd/client1
iroute 192.168.0.0 255.255.255.0
ifconfig-push 10.8.0.11 255.255.255.0


client.conf

client
dev tun
proto udp
remote vpn.ru
resolv-retry infinite
nobind
persist-key
persist-tun
remote-cert-tls server
cipher aes-128-cbc
auth sha1
comp-lzo
tls-client
remote-cert-tls server
key-direction 1



System setup

/etc/sysctl.conf uncomment net.ipv4.ip_forward=1
/etc/default/ufw DEFAULT_FORWARD_POLICY="ACCEPT"
April 7th 20 at 15:18
2 answers
April 7th 20 at 15:20
Yes, the config seems you are correct.
To check on the client, after connecting to the VPN to watch the routing table, there should be a route to the desired network through the VPN server.

But that's not enough computers in the network behind the VPN server must know the route to the computers in the VPN network. If the VPN server is not the default gateway for computers on the network, this route should be added on each computer (that needs to interact with customers VPN) manually (or using any available method, such as through DHCP options, etc.).
The connection goes through the router Kinetik in the routing I see the route:
10.15.17.0 via 10.8.0.1

And North 10.15.17.1 pings the ip address specified.
If remove push route 10.15.17.0 ceases to ping 10.15.17.1

That is, the campaign server does not transmit the response from the network inside it the desired route. - naomi22 commented on April 7th 20 at 15:23
@lyric.McKenzie61, Prescribed routes on the router which is connected to the server, 192.168.* pinouts go perfectly with other machines from the network 10.15.17.0 without any keys. If your router is connected to VPN key, begin to see the network 10.15.17.0 with other customers. But it's not right - naomi22 commented on April 7th 20 at 16:05
@jamar.Bode, the Router (also VPN server) is the default gateway for the network 10.15.17.0?

Can block the firewalls on both the router and the clients and hosts within the network.
On good it is necessary to take the client and a host within the network, disable them in fireworks, to run ping from the client to the host and look at the router with the analogue of tcpdump which packets to it fall on the VPN interface. In the absence of any packets (requests or responses) you will understand on which side of the issue. Maybe after disabling the firewalls, the problem will resolve itself, but it will mean that you need to properly configure firewalls. - ned_Wiegand commented on April 7th 20 at 15:26
@jamar.Bode, you can throw your vk help pliz is also a 3 day head scratching =) - russ.Wisoky commented on April 7th 20 at 15:29
@Amalia.Emard, Throw your write I have closed - naomi22 commented on April 7th 20 at 15:32
@jamar.Bode, https://vk.com/mrproj - russ.Wisoky commented on April 7th 20 at 15:35
@lyric.McKenzie61, Just a client 192.168.1.0 and 192.168.0.0 walk between a normally. On fire sin't even see the point.

Himself on any device can access any network where server in Windows just prescribed:

route-p add 192.168.1.0 mask 255.255.255.0 10.15.17.1 and all the rules - naomi22 commented on April 7th 20 at 15:38
@jamar.Bode,
Himself any device can get on any network

If that were the case, your question does not appear in principle.
Do this route on the VPN clients should appear after connecting to the VPN.
It is responsible for the push route Directive.
On fire sin't even see the point.

Firewalls as one of the participants in the network exchange may be in the business. I'm not saying that in your case this is so, but it is quite possible variant.
By the way, I did not see in the client-side config file Directive:
tls-auth ta.key 1
It must be, since you are on the server it prescribed.

My question you basically, probably, do not answer?
The router (also VPN server) is the default gateway for the network 10.15.17.0?
- ned_Wiegand commented on April 7th 20 at 15:41
tls-auth ta.key 0 is.

About route

I did it within the network where the North not to connect your router to openvpn

The router (also VPN server) is the default gateway for the network 10.15.17.0?


Do not understand this question? - naomi22 commented on April 7th 20 at 15:44
@jamar.Bode,
tls-auth ta.key 0 is.

What would it worked in the client configs need the same Directive, with only 1 end. And the key file on the client, the same need, the same as on the server. https://openvpn.net/community-resources/reference-...
However this is the question is not relevant.

Do not understand this question?

You don't know what "default gateway"?
Well take a look at the IP settings in Windows, see.
As far as I know the address of the router (the VPN server) within the network 10.15.17.1 - it should be the default gateway.

Himself on any device can access any network where server in Windows just prescribed:

route-p add 192.168.1.0 mask 255.255.255.0 10.15.17.1 and all the rules

On this basis come to the conclusion that the router (VPN server) is not the default gateway for the network 10.15.17.0. So you need to issue this command on a computer inside the network that would access the VPN clients. - ned_Wiegand commented on April 7th 20 at 15:47
@lyric.McKenzie61, I understand what You mean, no the gateway is the router which is where the server 10.15.17.254 (brain is already in full swing)

And the car is 10.15.17.1 openvpn

In principle, the problem is that I now see:
The client accesses the server 10.8.0.1 not understand where need to pass the route so that the client got on 10.15.17.2 in fact on openvpn needs to send this request on 10.15.17.254 and then have then get to the car. And a traceroute confirmed it, the server knows where to send the request.

10.8.0.1 is the same 10.15.17.1 - naomi22 commented on April 7th 20 at 15:50
@jamar.Bode, You don't see correctly!
Your customers VPN and the VPN server know where the network 10.15.17.0 how to send packages (as evidenced by the availability of appropriate routes in their routing table).
But your computers on the network 10.15.17.0 do not know where to send replies to the VPN clients, so they send these replies to the default gateway and the default gateway the same knows nothing about networks for VPN clients, so the answers just get lost.
So, see my second paragraph in the answer!
On each computer you issue a command
route-p add 192.168.1.0 mask 255.255.255.0 10.15.17.1
so he could send packets into the network for the client.
To register routes in a variety of ways, for example, if you use DHCP to hand out addresses, then you can configure the corresponding option in the DHCP server and the route will be registered automatically upon receipt of the address.

The problem has nothing to do with VPN - it is purely a problem of IP routing. - ned_Wiegand commented on April 7th 20 at 15:53
@lyric.McKenzie61, 5e496277d1b75788727357.png

Routes prescribed on the router, all internal devices, where the server can now see the machines in the 192 network, but the network 192 can't see the network 10.15.17 - naomi22 commented on April 7th 20 at 15:56
@jamar.Bode, what makes you think that?
Pings from hosts inside the network 10.15.17.0 reach host for WH Kitami?
If the answers to pings are coming, and feedback all right.

On what router you prescribed routes? Like the default gateway? Thus you have extended the path of the packages - they now have 2 times will be within the network take place. It is necessary to you? - ned_Wiegand commented on April 7th 20 at 15:59
@jamar.Bode,
192 but the network cannot see the network 10.15.17

A similar question on networks for VPN clients.
VPN clients for their networks are the default gateways?
If not, then you need to all hosts in the customer networks to prescribe the route to network behind VPN server. - ned_Wiegand commented on April 7th 20 at 16:02
@jamar.Bode,
If your router is connected to VPN key, begin to see the network 10.15.17.0 with other customers.

This is not understood. What is "your" router where you begin to see? - ned_Wiegand commented on April 7th 20 at 16:08
April 7th 20 at 15:22
It is necessary to diagnose the pieces. Turn on tcpdump and wireshark on each node in turn and see where the packets are being lost.

Find more questions by tags DebianOpenVPN