OpenVPN stopps working UDP

[symphoniker]

Hi

I had a well working OpenVPN installation but some days ago it stoped working. When I do switch to tcp on client and server (nothing else changed) everything works fine. So it must be an UDP related problem. As the connections are running over a very huge distance I would prefer running OpenVPN with UDP. It does occur on all the configured clients so I guess it is a server related problem.

The problem also occurs when the server and client are in the same network, so I guess it is not related to a NAT problem.

Server config:

Code: Select all

dev tun
proto udp
port 1194
ca /etc/openvpn/....
cert /etc/openvpn/....
key /etc/openvpn/....
dh /etc/openvpn/....
user openvpn
group openvpn
server 10.8.0.0 255.255.255.0
persist-key
persist-tun
status /var/log/openvpn-status.log
verb 3
push "redirect-gateway def1"
push "dhcp-option DNS ...."
push "dhcp-option DNS ...."
log-append /var/log/openvpn
comp-lzo

Client config

Code: Select all

dev tun
client
proto udp
remote xxx.xxx.xxx.xxx 1194
resolv-retry infinite
nobind
persist-key
persist-tun
ca ca.crt
cert ...
key ...
comp-lzo
verb 3

Server Log (Verb 6):

Code: Select all

Thu Apr 14 09:11:14 2016 us=356094 192.168.0.101:60180 UDPv4 READ [14] from [AF_INET]192.168.0.101:60180: P_CONTROL_HARD_RESET_CLIENT_V2 kid=0 [ ] pid=0 DATA len=0
Thu Apr 14 09:11:14 2016 us=356186 192.168.0.101:60180 TLS: Initial packet from [AF_INET]192.168.0.101:60180, sid=0c5afd23 ffd66575
Thu Apr 14 09:11:14 2016 us=356335 192.168.0.101:60180 UDPv4 WRITE [26] to [AF_INET]192.168.0.101:60180: P_CONTROL_HARD_RESET_SERVER_V2 kid=0 [ 0 ] pid=0 DATA len=0
Thu Apr 14 09:11:16 2016 us=471070 192.168.0.101:60180 UDPv4 WRITE [14] to [AF_INET]192.168.0.101:60180: P_CONTROL_HARD_RESET_SERVER_V2 kid=0 [ ] pid=0 DATA len=0
Thu Apr 14 09:11:16 2016 us=639550 192.168.0.101:60180 UDPv4 READ [14] from [AF_INET]192.168.0.101:60180: P_CONTROL_HARD_RESET_CLIENT_V2 kid=0 [ ] pid=0 DATA len=0
Thu Apr 14 09:11:16 2016 us=639795 192.168.0.101:60180 UDPv4 WRITE [22] to [AF_INET]192.168.0.101:60180: P_ACK_V1 kid=0 [ 0 ]
Thu Apr 14 09:11:20 2016 us=328148 192.168.0.101:60180 UDPv4 READ [14] from [AF_INET]192.168.0.101:60180: P_CONTROL_HARD_RESET_CLIENT_V2 kid=0 [ ] pid=0 DATA len=0
Thu Apr 14 09:11:20 2016 us=328305 192.168.0.101:60180 UDPv4 WRITE [26] to [AF_INET]192.168.0.101:60180: P_CONTROL_HARD_RESET_SERVER_V2 kid=0 [ 0 ] pid=0 DATA len=0
Thu Apr 14 09:11:28 2016 us=523123 192.168.0.101:60180 UDPv4 READ [14] from [AF_INET]192.168.0.101:60180: P_CONTROL_HARD_RESET_CLIENT_V2 kid=0 [ ] pid=0 DATA len=0
Thu Apr 14 09:11:28 2016 us=523399 192.168.0.101:60180 UDPv4 WRITE [26] to [AF_INET]192.168.0.101:60180: P_CONTROL_HARD_RESET_SERVER_V2 kid=0 [ 0 ] pid=0 DATA len=0
Thu Apr 14 09:11:44 2016 us=254204 192.168.0.101:60180 UDPv4 WRITE [14] to [AF_INET]192.168.0.101:60180: P_CONTROL_HARD_RESET_SERVER_V2 kid=0 [ ] pid=0 DATA len=0
Thu Apr 14 09:11:44 2016 us=843043 192.168.0.101:60180 UDPv4 READ [14] from [AF_INET]192.168.0.101:60180: P_CONTROL_HARD_RESET_CLIENT_V2 kid=0 [ ] pid=0 DATA len=0
Thu Apr 14 09:11:44 2016 us=843328 192.168.0.101:60180 UDPv4 WRITE [22] to [AF_INET]192.168.0.101:60180: P_ACK_V1 kid=0 [ 0 ]

Client Log (Verb 6):

Code: Select all

Thu Apr 14 09:12:17 2016 UDPv4 WRITE [14] to [AF_INET]192.168.0.78:1194: P_CONTROL_HARD_RESET_CLIENT_V2 kid=0 [ ] pid=0 DATA len=0
Thu Apr 14 09:12:17 2016 UDPv4 READ [0] from [undef]: DATA UNDEF len=-1
Thu Apr 14 09:12:19 2016 UDPv4 WRITE [14] to [AF_INET]192.168.0.78:1194: P_CONTROL_HARD_RESET_CLIENT_V2 kid=0 [ ] pid=0 DATA len=0
Thu Apr 14 09:12:23 2016 UDPv4 WRITE [14] to [AF_INET]192.168.0.78:1194: P_CONTROL_HARD_RESET_CLIENT_V2 kid=0 [ ] pid=0 DATA len=0
Thu Apr 14 09:12:31 2016 UDPv4 WRITE [14] to [AF_INET]192.168.0.78:1194: P_CONTROL_HARD_RESET_CLIENT_V2 kid=0 [ ] pid=0 DATA len=0

As it seems clear that the servers response does not reach the client I did some package capturing on server and client:

Server:

Code: Select all

09:16:33.550960 IP 192.168.0.101.54862 > 192.168.0.78.1194: UDP, length 14
09:16:33.553050 IP 192.168.0.78.1024 > 192.168.0.101.54862: UDP, length 26
09:16:34.774581 IP 192.168.0.101.54862 > 192.168.0.78.1194: UDP, length 14
09:16:34.775303 IP 192.168.0.78.1024 > 192.168.0.101.54862: UDP, length 22
09:16:36.004379 IP 192.168.0.78.1024 > 192.168.0.101.54862: UDP, length 14
09:16:39.796842 IP 192.168.0.101.54862 > 192.168.0.78.1194: UDP, length 14
09:16:39.797559 IP 192.168.0.78.1024 > 192.168.0.101.54862: UDP, length 22
09:16:40.115430 IP 192.168.0.78.1024 > 192.168.0.101.54862: UDP, length 14
09:16:49.117692 IP 192.168.0.78.1024 > 192.168.0.101.54862: UDP, length 14

Client:

Code: Select all

MessageNumber	DiagnosisTypes	Timestamp	TimeElapsed	Source	Destination	Module	Summary	
217	None	2016-04-14T09:16:33.7967782		        192.168.0.101	192.168.0.78	UDP	SrcPort: 54862, DstPort: 1194, Length: 22	
218	None	2016-04-14T09:16:33.8033921	0,0000009	192.168.0.78	192.168.0.101	UDP	SrcPort: 1024, DstPort: 54862, Length: 34	
238	None	2016-04-14T09:16:35.0188511		        192.168.0.101	192.168.0.78	UDP	SrcPort: 54862, DstPort: 1194, Length: 22	
239	None	2016-04-14T09:16:35.0221133	0,0000012	192.168.0.78	192.168.0.101	UDP	SrcPort: 1024, DstPort: 54862, Length: 30	
261	None	2016-04-14T09:16:36.2512328	0,0000013	192.168.0.78	192.168.0.101	UDP	SrcPort: 1024, DstPort: 54862, Length: 22	
310	None	2016-04-14T09:16:39.9080696		        192.168.0.101	192.168.0.78	UDP	SrcPort: 54862, DstPort: 1194, Length: 22	
311	None	2016-04-14T09:16:40.0446109	0,0000025	192.168.0.78	192.168.0.101	UDP	SrcPort: 1024, DstPort: 54862, Length: 30	
319	None	2016-04-14T09:16:40.5270957	0,0000017	192.168.0.78	192.168.0.101	UDP	SrcPort: 1024, DstPort: 54862, Length: 22	
432	None	2016-04-14T09:16:49.3691061	0,0000025	192.168.0.78	192.168.0.101	UDP	SrcPort: 1024, DstPort: 54862, Length: 22	
627	None	2016-04-14T09:17:06.1415660	0,0000008	192.168.0.78	192.168.0.101	UDP	SrcPort: 1024, DstPort: 54862, Length: 22	
	

As UDP packages are arriving on the client machine but not in OpenVPN client seems a bit strange to me. My question about this is if it is normal that the server does send packages from a different port (1024) than it is configured to (1194).

Do you have any further suggestions to investigate this issue?

thx in advance
and all the best

[Traffic]

Do you use iptables ?

[symphoniker]

Yes I do have some iptable rules in place to avoid vpn users to access some parts of the private network. But for testing purposes I did a

iptables --flush

So currently my IP tables are empty. But this does not change anything on the problem.

[Traffic]

It does occur on all the configured clients so I guess it is a server related problem.

The problem also occurs when the server and client are in the same network

Maybe you have a hardware problem ..

[symphoniker]

Thanks for your input. I checked my hardware as well (networkcable, switch port, server hardware) but it does not change anything.

By know I found out that it is not OpenVPN related. But if you have any further advices I would be very glad about it.

I checked the network connection with netcat and found out that:

- The OpenVPN Server machine acting as UDP client works well
- TCP is working well

But: When the OpenVPN-Server machine is acting as UDP Server it answers request on the wrong port.

netcat -u -l 4444 but the messages from the server back to the client leave the client again on port 1024.
Also just the first message from the client arrives on the server but no more and no messages from the server
to the client are delivered correcty. (I can see them in tcpdump but on the wrong port)

I hope someone has an idea where I could do some more research.

[symphoniker]

Finally I found the problem. So this can be marked as solved.

By adding

local xxx.xxx.xxx.xxx

to my OpenVPN configuration everything works as expected. For me this is quite strange that I have to add this for UDP but TCP works fine without. Beside this I do not have special network devices configured on my server. Just eth0, lo, tun0 (from OpenVPN).

But anyway. It is working again.
Thx for your help and all the best

(I found the problem with netcat that worked well when binding to a fixed adress instead of just to a port)

[Traffic]

It sounds like you have a network config issue ..

By adding

local xxx.xxx.xxx.xxx

to my OpenVPN configuration everything works as expected

This simply configures openvpn to listen on one specific IP .. otherwise it will listen on all local IPs. (excluding tun)

[symphoniker]

Sorry for my late answer. I did check that and it looks like an update did mess up my netwok configuration (dhcp running with static ip configured) After fixing this everything works as expected.

Thx for your help.

[Traffic]

Thanks for letting us know your solution