bad source address from client

isj4

We were deploying 4 new client boxes yesterday. Due to a NAT problem I had to change the keepalive settings and restart the openvpn server. After that all but one of the clients reestablished their tunnel. Due to ip-address reshuffling one client (cucumber) is stuck believing it has an IP-address which has been reassigned to another client. The clients are headless and located in broom cupbards etc. at remote locations, so I'd very much prefer that they can reestablish VPN tunnels unattendedly.
Log&configuration below.

Q1: would enabling the administrative interface and do a "kill cucumber" resolve this problem and make the client reconnect properly?

Q2: is there a way of automatically resolving this problem? The client appears to believe that everything is fine and won't re-initialize the tunnel.

syslog:

Apr  8 22:33:57 kgbvax ovpn-openvpn-udp[10714]: cucumber/128.66.0.100:46742 MULTI_sva: pool returned IPv4=10.221.0.4, IPv6=1::2000:0:147f:0
Apr  8 22:33:57 kgbvax ovpn-openvpn-udp[10714]: cucumber/128.66.0.100:46742 MULTI: Learn: 10.221.0.4 -> cucumber/128.66.0.100:46742
Apr  8 22:33:57 kgbvax ovpn-openvpn-udp[10714]: cucumber/128.66.0.100:46742 MULTI: primary virtual IP for cucumber/128.66.0.100:46742: 10.221.0.4
Apr  8 22:34:27 kgbvax ovpn-openvpn-udp[10714]: cucumber/128.66.0.100:46742 Authenticate/Decrypt packet error: packet HMAC authentication failed
Apr  8 22:34:45 kgbvax ovpn-openvpn-udp[10714]: cucumber/128.66.0.100:46742 Authenticate/Decrypt packet error: packet HMAC authentication failed
Apr  8 22:35:24 kgbvax ovpn-openvpn-udp[10714]: cucumber/128.66.0.100:46742 MULTI: bad source address from client [10.221.0.5], packet dropped
Apr  8 22:36:24 kgbvax ovpn-openvpn-udp[10714]: cucumber/128.66.0.100:46742 MULTI: bad source address from client [10.221.0.5], packet dropped
(ad nauseam)
Apr  9 11:40:04 kgbvax ovpn-openvpn-udp[10714]: cucumber/128.66.0.100:46742 MULTI: bad source address from client [10.221.0.5], packet dropped

# cat /run/openvpn.openvpn-udp.status

OpenVPN CLIENT LIST
Updated,Thu Apr  9 12:28:08 2015
Common Name,Real Address,Bytes Received,Bytes Sent,Connected Since
rabbit1,128.66.188.188:1154,1599892,818826,Wed Apr  8 22:37:08 2015
rabbit2,128.66.188.188:1194,356730,357579,Wed Apr  8 22:37:08 2015
cucumber,128.66.0.100:46742,581103,349655,Wed Apr  8 22:33:56 2015
carrot,128.66.0.100:47357,1096498,603555,Wed Apr  8 22:34:09 2015
rabbit4,128.66.188.188:1157,484605,2070083,Wed Apr  8 22:37:09 2015
rabbit3,128.66.188.188:1158,362021,359036,Wed Apr  8 22:37:10 2015
ROUTING TABLE
Virtual Address,Common Name,Real Address,Last Ref
10.221.0.4,cucumber,128.66.0.100:46742,Wed Apr  8 22:53:23 2015
10.221.0.8,rabbit4,128.66.188.188:1157,Wed Apr  8 23:21:04 2015
10.221.0.5,carrot,128.66.0.100:47357,Thu Apr  9 12:27:40 2015
10.221.0.6,rabbit1,128.66.188.188:1154,Thu Apr  9 12:28:00 2015
10.221.0.7,rabbit2,128.66.188.188:1194,Wed Apr  8 23:02:13 2015
10.221.0.9,rabbit3,128.66.188.188:1158,Wed Apr  8 23:01:41 2015
GLOBAL STATS
Max bcast/mcast queue length,0
END

# cat /etc/openvpn/openvpn-udp.conf

port 1194
proto udp
dev tun0
topology p2p
server 10.221.0.0 255.255.192.0
push "route 10.221.128.0 255.255.255.0"

tls-auth ta.key 0

dh dh.pem
ca ca.crt
cert server.crt
key server.key
askpass passphrase
crl-verify crl.pem

comp-lzo adaptive
keepalive 10 120

verb 5

learn-address /etc/openvpn/learn-address.sh

Server OpenVPN version: 2.2.1
Client OpenVPN version: 2.3.4

Traffic

For your information, you have posted this to the "OpenVPN Access Server" board ..
You should have posted in "OpenVPN Server Administratoin (For FOSS Version):
https://forums.openvpn.net/server-administration-f4.html

isj4 wrotebad source address from client [10.221.0.5], packet dropped

normally resolved using --client-config-dir & --iroute with fixed VPN IP client address ..

isj4 wrotetopology p2p

is now deprecated and you would do better with --topology subnet. Topology is automatically --pushed when using --server .. so none of your clients should notice the change.

isj4 wroteQ1: would enabling the administrative interface and do a "kill cucumber" resolve this problem and make the client reconnect properly?

it should ..

isj4 wroteQ2: is there a way of automatically resolving this problem? The client appears to believe that everything is fine and won't re-initialize the tunnel.

post client config and log please.

isj4

Traffic wroteFor your information, you have posted this to the "OpenVPN Access Server" board ..
You should have posted in "OpenVPN Server Administratoin (For FOSS Version):
https://forums.openvpn.net/server-administration-f4.html

Sorry about that. I didn't notice the difference. Feel free to move this thread to the appropriate board.

Traffic wrote
isj4 wrotebad source address from client [10.221.0.5], packet dropped
normally resolved using --client-config-dir & --iroute with fixed VPN IP client address ..

Yes, I read that several places, but I'd prefer to not have the administrative overhead of that. I don't care which IP address the clients are assigned.

Traffic wrote
isj4 wrotetopology p2p
is now deprecated and you would do better with --topology subnet. Topology is automatically --pushed when using --server .. so none of your clients should notice the change.

Interesting. The documentation is quite confusing at this point. Under "topology p2p" it says ... use --ifconfig-pool-linear, but under --ifconfig-pool-linear it says use --topology p2p.

Traffic wrote
isj4 wroteQ1: would enabling the administrative interface and do a "kill cucumber" resolve this problem and make the client reconnect properly?
it should ..

Ok, I'll enable the administrative interface and see if it works the next time the problem appears.

Traffic wrote
isj4 wroteQ2: is there a way of automatically resolving this problem? The client appears to believe that everything is fine and won't re-initialize the tunnel.
post client config and log please.

cucumber:~ # cat /etc/openvpn/openvpn.conf

client
dev tun

<connection>
remote vpn.pumpkin.example.net 1194 udp
</connection>

ca ca.crt
cert cucumber.crt
key cucumber.key
tls-auth ta.key 1
verify-x509-name CN=vpn.pumpkin.example.net
comp-lzo adaptive
askpass passphrase
verb 3

Traffic

isj4 wroteI'd prefer to not have the administrative overhead of that

You can safely ignore the dropped packets or firewall them off on your client.

Client config:

isj4 wrote<connection>
remote vpn.pumpkin.example.net 1194 udp
</connection>

Due to problems using <connection> blocks I stopped using them .. you can have multiple --remote statements in one client config without <connection> blocks (I also have a dummy entry which does not resolve to help).

Unless you have a specific need, I would use --nobind in the client config.