I have a OpenVPN server which have 2 "types" of clients:
- with a DHCP assigned address. These are able to ping the server without any issue.
- with a static assigned address via a cliens specific file. These can only ping the server for a few seconds after the server is (re-)started.
My server has the ip 10.10.0.1 and the client with the static ip 10.10.0.20
Clients with dynamic addresses have ip's in the range 10.10.1.2 - 10.10.255.254
When i check the server logs is see MULTI: bad source address from client [10.10.0.20], packet dropped
Some Googling learned me that it has to do with routing at the server side but i cannot find whats wrong. I also cannot understand that pinging the server (or the other way arround) works for a short period after the server is (re-)started
Server config:
port 3194
proto udp
dev tun
mode server
topology subnet
ca server_cert/ca.crt
cert server_cert/ovpn-server.crt
key server_cert/ovpn-server.key # This file should be kept secret
dh server_cert/dh.pem
tls-server
cipher AES-256-CBC
ifconfig 10.10.0.1 255.255.0.0
ifconfig-pool 10.10.1.2 10.10.255.254 255.255.0.0
;route 10.10.0.0 255.255.0.0
;push "route-gateway 10.10.0.1 255.255.0.0"
push "route 10.10.0.0 255.255.0.0"
ifconfig-pool-persist ipp.txt
client-config-dir ccd
client-to-client
duplicate-cn
keepalive 10 120
persist-key
persist-tun
status openvpn-status.log
log-append /var/log/openvpn.log
verb 4
explicit-exit-notify 1
Serverside client specific config (ccd/device_y):
ifconfig-push 10.10.0.20 255.255.0.0
iroute 10.10.0.20 255.255.0.0 # I also tried without this line!
Client config:
root@ngin-web01:/home/xxxx# cat /etc/openvpn/client.conf
client
dev tun
proto udp
port 3194
remote vpn.domain.de 3194
#resolv-retry infinite
nobind
#persist-key
#persist-tun
# Certificates
ca keys/ca.crt
cert /etc/openvpn/keys/ngin-web01.crt
key /etc/openvpn/keys/ngin-web01.key
# Cryptographic cipher
cipher AES-256-CBC
# Loglevel
log-append /var/log/openvpn.log
verb 6
Client logs:
...
...
Thu Sep 24 12:49:51 2020 us=673375 UDP WRITE [108] to [AF_INET]195.14.252.254:3194: P_DATA_V2 kid=0 DATA len=107
Thu Sep 24 12:49:52 2020 us=35844 UDP READ [40] from [AF_INET]195.14.252.254:3194: P_DATA_V2 kid=0 DATA len=39
Thu Sep 24 12:49:52 2020 us=697265 TUN READ [84]
Thu Sep 24 12:49:52 2020 us=697488 UDP WRITE [108] to [AF_INET]195.14.252.254:3194: P_DATA_V2 kid=0 DATA len=107
Thu Sep 24 12:49:53 2020 us=721179 TUN READ [84]
Thu Sep 24 12:49:53 2020 us=721379 UDP WRITE [108] to [AF_INET]195.14.252.254:3194: P_DATA_V2 kid=0 DATA len=107
Thu Sep 24 12:49:54 2020 us=745211 TUN READ [84]
Thu Sep 24 12:49:54 2020 us=745412 UDP WRITE [108] to [AF_INET]195.14.252.254:3194: P_DATA_V2 kid=0 DATA len=107
Thu Sep 24 12:49:55 2020 us=769216 TUN READ [84]
...
...
Server logs:
Thu Sep 24 12:49:51 2020 us=674779 axc-ngin-web01/10.128.12.20:52693 MULTI: bad source address from client [10.10.0.20], packet dropped
Thu Sep 24 12:49:52 2020 us=699030 axc-ngin-web01/10.128.12.20:52693 MULTI: bad source address from client [10.10.0.20], packet dropped
Thu Sep 24 12:49:53 2020 us=723591 axc-ngin-web01/10.128.12.20:52693 MULTI: bad source address from client [10.10.0.20], packet dropped
Thu Sep 24 12:49:54 2020 us=746800 axc-ngin-web01/10.128.12.20:52693 MULTI: bad source address from client [10.10.0.20], packet dropped
UPDATE
I also noticed this in the server logs which makes me think that it "learnes" that the device ngin-web01 has the ip 10.128.12.21 which is its real ip. Can this be related to the issue i'm running into?
Fri Sep 25 09:59:20 2020 us=631531 10.128.12.21:36203 [ngin-web01] Peer Connection Initiated with [AF_INET]10.128.12.21:36203
Fri Sep 25 09:59:20 2020 us=631861 ngin-web01/10.128.12.21:36203 MULTI: Learn: 10.10.0.20 -> ngin-web01/10.128.12.21:36203
Fri Sep 25 09:59:20 2020 us=631898 web01/10.128.12.21:36203 MULTI: primary virtual IP for ngin-web01/10.128.12.21:36203: 10.10.0.20
