TUN write error

unkmunk

Hello all, I just tried openvpn connect for ios app and it seems to be what I have been eagerly awaiting.

After some initial confusion with inline certs, keys, etc. I managed to get a profile that actually connects.

Although the profile connects, no traffic seems to flow. The main oddity I see in the log is
-------------------------------------
2013-01-30 00:04:11 Connected via tun
2013-01-30 00:04:11 EVENT: CONNECTED user@server.example.com:1194 (ww.xx.yy.zz) via /UDPv4 on tun/192.168.2.138/
2013-01-30 00:04:12 TUN write error: cannot identify IP version for prefix
2013-01-30 00:04:14 TUN write error: cannot identify IP version for prefix
2013-01-30 00:04:19 TUN write error: cannot identify IP version for prefix
2013-01-30 00:04:24 TUN write error: cannot identify IP version for prefix
2013-01-30 00:04:29 TUN write error: cannot identify IP version for prefix
2013-01-30 00:04:39 TUN write error: cannot identify IP version for prefix
2013-01-30 00:04:48 TUN write error: cannot identify IP version for prefix
2013-01-30 00:04:58 TUN write error: cannot identify IP version for prefix
2013-01-30 00:05:08 TUN write error: cannot identify IP version for prefix
2013-01-30 00:05:48 Session invalidated
2013-01-30 00:05:48 Client terminated, restarting in 2...
-------------------------------------

Should it matter, the TUN is on an ios 6.1 device on an AT&T iphone 4.
The server is the community edition.... I need to get back to the office to check the exact version, I may be back a few releases.

Any push in the right direction would be greatly appreciated.

jamesyonan

It's probably an issue where the client and server-side options are not compatible in some way.

The "cannot identify IP version for prefix" error occurs when the client receives an IP packet from the server that it can't identity as being either IPv4 or IPv6.

Check the server side log for warnings.

unkmunk

Thanks for the reply, and from 'the man' himself no less. First let me tell you just exactly how grateful I am for your generous contributions to the community. Thank you!

As it turns out I am quite a bit more than "a few releases behind". Actually, I am running 2.0.9 on the server (time really flies). I'll update it when time and user load permit it.

In the meantime, I reviewed the server log as you suggested.

I do have a number of
Wed Jan 30 06:51:52 2013 xxxx/aa.bb.cc.dd:64974 Need IPv6 code in mroute_extract_addr_from_packet
Wed Jan 30 06:51:52 2013 xxxx/aa.bb.cc.dd:64974 Need IPv6 code in mroute_extract_addr_from_packet
but these aren't particularly unusual for me and don't normally affect my traffic flow.

A little further down the log (in a different connection attempt) I have
Wed Jan 30 07:07:02 2013 xxxx/aa.bb.cc.dd:55230 FRAG_IN error flags=0x4500002c: spurrious FRAG_WHOLE flags
Wed Jan 30 07:07:02 2013 xxxx/aa.bb.cc.dd:55230 FRAG_IN error flags=0x4500002c: spurrious FRAG_WHOLE flags
Wed Jan 30 07:07:03 2013 xxxx/aa.bb.cc.dd:55230 FRAG_IN error flags=0x4500002c: spurrious FRAG_WHOLE flags
Wed Jan 30 07:07:03 2013 xxxx/aa.bb.cc.dd:55230 NOTE: --mute triggered...
Wed Jan 30 07:07:40 2013 87 variation(s) on previous 10 message(s) suppressed by --mute
Wed Jan 30 07:07:40 2013 read UDPv4: Connection reset by peer (WSAECONNRESET) (code=10054)
Wed Jan 30 07:07:50 2013 read UDPv4: Connection reset by peer (WSAECONNRESET) (code=10054)
Wed Jan 30 07:08:00 2013 read UDPv4: Connection reset by peer (WSAECONNRESET) (code=10054)
Wed Jan 30 07:08:11 2013 read UDPv4: Connection reset by peer (WSAECONNRESET) (code=10054)
Wed Jan 30 07:08:20 2013 read UDPv4: Connection reset by peer (WSAECONNRESET) (code=10054)
Wed Jan 30 07:08:31 2013 read UDPv4: Connection reset by peer (WSAECONNRESET) (code=10054)
Wed Jan 30 07:08:41 2013 read UDPv4: Connection reset by peer (WSAECONNRESET) (code=10054)
Wed Jan 30 07:08:50 2013 read UDPv4: Connection reset by peer (WSAECONNRESET) (code=10054)
Wed Jan 30 07:09:00 2013 xxxx/aa.bb.cc.dd:55230 [mbaird@tecny.us.intdk] Inactivity timeout (--ping-restart), restarting
Wed Jan 30 07:09:00 2013 xxxx/aa.bb.cc.dd:55230 SIGUSR1[soft,ping-restart] received, client-instance restarting

My best guess is that the server code update will solve the problem and at this point probably addresses a number of other issues as well (regardless of whether I ever noticed them or not).

Lastly, again, thank you.

alchemyx

Hello,

Did you manage to solve it somehow? I get same errors altough configuration
items on client and server are identical.

ranimi

Hi have the same exact error: I can connect to the server but no traffic.

Did you solve the issue?

alchemyx

I had to prepare configuration of OpenVPN just for iOS devices,
I removed two items from our typical config:

mssfix 1000
fragment 1000

And client config looks like this (funny thing is it contains "fragment" but works fine):

remote host1 1196
remote host2 1196
client
fragment 1000
dev tun
proto udp
resolv-retry infinite
nobind
user nobody
group nogroup
persist-key
persist-tun
ns-cert-type server
key-direction 1
cipher AES-256-CBC
verb 3

<ca>
...
</ca>

<tls-auth>
...
</tls-auth>

<cert>
...
</cert>

<key>
...
</key>

ranimi

My config is very similar:

#OpenVPN Client conf
tls-client
client
dev tun
proto udp
tun-mtu 1500
remote myRemoteHost 1194
float
cipher BF-CBC
verb 3
ns-cert-type server
<key>
...
</key>
<ca>
...
</ca>
<cert>
...
</cert>

alchemyx

Are you sure that cipher is supported by iOS client?

ranimi

alchemyx wroteAre you sure that cipher is supported by iOS client?

I don't really know.
I just tried to remove the line without any visible effect: it stills connect to the VPN server, but no traffic and "TUN write error" messages.

jamesyonan

Did you check the server-side log file? Often it will show more detailed warnings about configuration incompatibilities between client and server.

James

ranimi

jamesyonan wroteDid you check the server-side log file? Often it will show more detailed warnings about configuration incompatibilities between client and server.

James

I did and I found nothing strange.

I believe the problems are due to the unsupported "fragment" directiv which we found is essential for all our vpn clients around the country...