Need help with Windows client

denf

Hello!

I`ve got a problem: UDP traffic from windows client cant reach server. Ping and TCP works fine.

Server is on a linux box with a 3g modem with fixed ip. Started with: openvpn --cd /etc/openvpn --config server.conf --iproute /bin/ip --auth none
Config:
port 1194
proto udp
dev tun
ca ca.crt
cert server.crt
key server.key # This file should be kept secret
dh dh1024.pem
server 10.8.0.0 255.255.255.0
ifconfig-pool-persist ipp.txt
client-to-client
duplicate-cn
keepalive 60 240
cipher none
max-clients 10
persist-key
persist-tun
status openvpn-status.log
verb 3

Client is WinXP machine with Ethernet and TAP-Win32 Adapter V9.
Config:
client
dev tun
proto udp
remote XX.XX.XXX.XXX 1194 #IP address of server`s modem
resolv-retry infinite
nobind
ca ca.crt
cert client3.crt
key client3.key
cipher none
verb 3
auth none

Connection estableshes and i can ping server with ping 10.8.0.1 and from server i can ping client with ping 10.8.0.6
But when im trying to send UDP packet from client it doesnt reach server.

janjust

that's a firewall issue on either client or server - try disabling the firewalls on both ends to see if that helps (for DEBUGGING only!)

denf

Thanks for answer.

Ive disabled firewall on windows and monitor incoming traffic on linux box with tcpdump. And i dont see any incoming traffic when i send UDP packet from windows.
I start 2 wiresharks. First monitors TAP-Win32, second - Ethernet. When i send UDP packet i see that packet in first wireshark but dont see the outgoing openvpn`s packet in second wireshark(ethernet). Looks like packets dropped somewhere on the client`s side. 🙁

janjust

what happens if you run 'traceroute -n <client VPN IP>' on the server? On linux this will send UDP packets to the client, which should respond with ICMP packets (if the windows firewall is turned OFF)

denf

root@192.168.0.152:~# traceroute -n 10.8.0.6
traceroute to 10.8.0.6 (10.8.0.6), 30 hops max, 38 byte packets
1 10.8.0.6 112.969 ms 138.713 ms 119.345 ms
root@192.168.0.152:~#

On the Windows client side tracert works fine too. But Windows tracert sends ICMP echo requests so it works like ping command.

janjust

root@192.168.0.152:~# traceroute -n 10.8.0.6
traceroute to 10.8.0.6 (10.8.0.6), 30 hops max, 38 byte packets
1 10.8.0.6 112.969 ms 138.713 ms 119.345 ms

this proves that UDP traffic is flowing over the VPN - whatever else you're using to send UDP traffic is doing something odd/wrong.

denf

janjust wrotethis proves that UDP traffic is flowing over the VPN - whatever else you're using to send UDP traffic is doing something odd/wrong.

Not true. UDP traffic is flowing from linux box to windows but not from windows client to linux server. Im using this tool for testing http://www.ks-soft.net/ip-tools.eng/index.htm
It has UDP Scaner for sending UDP packets.

janjust

ah true - traceroute sends UDP but returns ICMP ...

so the Windows client can receive UDP traffic but it cannot send it - run wireshark on the windows client to see if the UDP traffic is actually sent out over the tunnel (tap-win32 adapter). If that is the case then there might a firewall on the server side that is blocking traffic - run 'tcpdump' or 'wireshark' there to see if anything is coming in.

denf

janjust wroteso the Windows client can receive UDP traffic but it cannot send it - run wireshark on the windows client to see if the UDP traffic is actually sent out over the tunnel (tap-win32 adapter).

Already done it 🙂

denf wroteThanks for answer.

Ive disabled firewall on windows and monitor incoming traffic on linux box with tcpdump. And i dont see any incoming traffic when i send UDP packet from windows.
I start 2 wiresharks. First monitors TAP-Win32, second - Ethernet. When i send UDP packet i see that packet in first wireshark but dont see the outgoing openvpn`s packet in second wireshark(ethernet). Looks like packets dropped somewhere on the client`s side. 🙁

janjust wroteIf that is the case then there might a firewall on the server side that is blocking traffic - run 'tcpdump' or 'wireshark' there to see if anything is coming in.

Ran tcpdump on server to monitor packets to 1194 port but no packets came in.

janjust

I've just tried to duplicate your setup and everything works for me ...
Add

verb 7

to the client config file and reconnect the client; then run some UDP sending tool (I used 'iperf') ; the client log file shoudl now be filled up with messages of the form

Mon May 30 10:33:37 2011 us=359000 TUN READ [1498]
Mon May 30 10:33:37 2011 us=375000 TLS: tls_pre_encrypt: key_id=0
Mon May 30 10:33:37 2011 us=375000 TCPv4_CLIENT WRITE [1533] X.X.X.X:1194: P_DATA_V1 kid=0 DATA len=1532

the first line is data coming in on the tap-win32 adapter, the third line is data being written out to the VPN server.
do you see similar lines?

denf

Tried iperf and saw strange thing:

C:\Documents and Settings\Admin>d:\work\iperf -u -c 10.8.0.1 -p 12345 -n 1 -l 1
WARNING: the UDP buffer was increased to 12 for proper operation
------------------------------------------------------------
Client connecting to 10.8.0.1, UDP port 12345
Sending 12 byte datagrams

I wanted to send 1 byte ( -l 1 ) but iperf gave me the big WARNING about UDP buffer size.
Ive changed payload in my program from 1 to 12 bytes and it works now. 🙂

Maybe Win32-TAP driver simply drops UDP packets less than 12 bytes as malformed or so?
Anyway, Thank you. Looks like we solved problem.

janjust

there shouldn't be a minimum payload size, but 'iperf' seems to insist on a minimum of 12 bytes ; even when doing iperf runs between 2 linux hosts, and not using a VPN at all, I get

WARNING: the UDP buffer was increased to 12 for proper operation
WARNING: option -l has implied compatibility mode

Glad to hear things are now working.