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: [oconf=server] 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 [/oconf] Serverside client specific config (ccd/device_y): [oconf=server] 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! [/oconf] Client config: [oconf=client] 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 [/oconf] Client logs: [code] ... ... 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] ... ... [/code] Server logs: [code] 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 [/code]

[solved] Why logs my OpenVPN server “MULTI: bad source address from client”?

CodeNinja

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

CodeNinja

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

TinCanTech

Because your server config is a complete mess ..

Use the sample server config or use a script like Nyr or angristan.

CodeNinja

I solved the issue. The certificate (of the static client) was distributed to 2 servers by a human mistake. Because of this, traffic was routed to the correct server as long as the second (wrong) server was still connecting. When the second server was connected, the problem was facing up.