[Solved]Strange Udp packet drop

seneca

Hello everyone,
we have a server with many clients configured with udp tunnel, the rest of the configuration is the default we find in the package: 2.0.9 (client) and 2.3.2 (server). The tunnel works fine in general, but we have a strange behaviour when is active. The server is on and the client is connected to the server with its tunnel opened. The client is an industrial device (linux) and needs a software to be discovered; this software launches an UDP broadcast and the device replies with another packet (we wrote both software). If tunnel is off it works, but when it is on the packet arrives to the device (we saw it with tcpdump) but is not delivered to the listening daemon. If the discovering PC and the device are on the same network it works, but through different networks (but same switch) it doesn't work.

It seem to be a routes table problem, someone can help or can put us on the right path?
Thanks for your time.

maikcat

are you using broadcasts?
how did you configured openvpn?

Michael.

seneca

The connection between client and server is like this:

The server is exposed to the internet with its IP and Port
The client have an ethernet adapter and a 3gmodem
The ethernet is connected to a switch (we talk about it after)
The VPN go through the modem with a 3G connection

Connected to the switch there is a desktop PC and our software that want to guess the local ip of the device (client) with a broadcast UPD, this packet arrive to the device correctly but not arrive to the service (that we wrote). We would specify that we do not want to broadcast through VPN but only locally through the ethernet where the VPN is not channelled. Otherwise the udp broadcast arrives to the service if the device and the pc are on the same address range (local lan) but not to arrives if adresses are different (ex. 192.168.1.10/24 PC, 192.168.2.50/24 for the device).

Server Configuration:

port 0
proto udp
dev tun
ca C:\Program Files\OpenVPN\config\ca.crt
cert C:\Program Files\OpenVPN\config\server.crt
key C:\Program Files\OpenVPN\config\server.key
dh C:\Program Files\OpenVPN\config\dh1024.pem
server 10.9.7.0 255.255.255.0
ifconfig-pool-persist ipp.txt
client-config-dir ccd
client-to-client
keepalive 10 120
comp-lzo
persist-key
persist-tun
status openvpn-status.log
verb 3
management 0.0.0.0 7500

Client Configuration:
client
dev tun
port 1194
proto udp

remote X.Y.Z 1194
nobind

ca /home/config/vpn/ca.crt
cert /home/config/vpn/tws4.crt
key /home/config/vpn/tws4.key

comp-lzo
persist-key
persist-tun

verb 3

Thanks for thw interest!

maikcat

let me see if i got this right..

we have a server with many clients configured with udp tunnel

The server is exposed to the internet with its IP and Port

your openvpn server is a public exposed server

The client is an industrial device (linux)

The client have an ethernet adapter and a 3gmodem
The ethernet is connected to a switch (we talk about it after)
The VPN go through the modem with a 3G connection

your vpn client is a linux appliance with a 3g modem for internet access and an ethernet based
connection to a switch

Connected to the switch there is a desktop PC and our software that want to guess the local ip of the device (client) with a broadcast UPD

in your clients lan you have a pc which runs a discovery software for the linux vpn clients
this is using udp broadcast to your clients LAN ip to talk to the device, correct?

this packet arrive to the device correctly but not arrive to the service (that we wrote)

openvpn justs creates a new virtual interface on your client, i dont think it alters
your lan connection in any way , also if you use tcpdump and verify that the packet is indeed
recieved by the client i think that its impossible that its not recieved by your app....

Michael.

seneca

Everything you said is correct and you understood right.

For the question:

in your clients lan you have a pc which runs a discovery software for the linux vpn clients
this is using udp broadcast to your clients LAN ip to talk to the device, correct?

Yes, is correct, on the device there is a server we made to receive the broadcast UDP packet.

We see on the device, with tcpdump, the packet but it doesn't reach the daemon server. If we disconnect the opevpn start to work correctly, for this i told you that my suspect is the routes table.
Thanks for your time.

Traffic

seneca wroteWe see on the device, with tcpdump, the packet but it doesn't reach the daemon server. If we disconnect the opevpn start to work correctly, for this i told you that my suspect is the routes table.

routes table details ?

maikcat

i dont think its routing related because if the package was being
forwarded for any reason you would see it when using tcpdump,

any chance that filtering is performed on client?

just curious, can you test with openvpn stoped on client but add an alias interface? (to simulate 2 interfaces)

Michael.

seneca

We configured a second interface and, to complete the test, we tested with the 3g ppp on and off: the result is that work in all cases.
Thanks for your interests

seneca

Traffic wrote
seneca wroteWe see on the device, with tcpdump, the packet but it doesn't reach the daemon server. If we disconnect the opevpn start to work correctly, for this i told you that my suspect is the routes table.
routes table details ?

Destination Gateway Genmask Flags Metric Ref Use Iface
10.64.64.64 0.0.0.0 255.255.255.255 UH 0 0 0 ppp0
10.9.7.22 0.0.0.0 255.255.255.255 UH 0 0 0 tun0
192.168.100.0 10.9.7.22 255.255.255.0 UG 0 0 0 tun0
192.168.100.0 0.0.0.0 255.255.255.0 U 0 0 0 eth0
192.168.130.0 10.9.7.22 255.255.255.0 UG 0 0 0 tun0
10.9.7.0 10.9.7.22 255.255.255.0 UG 0 0 0 tun0
192.168.110.0 10.9.7.22 255.255.255.0 UG 0 0 0 tun0
192.168.120.0 10.9.7.22 255.255.255.0 UG 0 0 0 tun0
192.168.84.0 0.0.0.0 255.255.252.0 U 0 0 0 eth0
0.0.0.0 10.64.64.64 0.0.0.0 UG 0 0 0 ppp0

maikcat

192.168.100.0 10.9.7.22 255.255.255.0 UG 0 0 0 tun0
192.168.100.0 0.0.0.0 255.255.255.0 U 0 0 0 eth0

what is 192.168.100.0 network?

can you post the output of ifconfig as well?

Michael.

seneca

maikcat wrote
192.168.100.0 10.9.7.22 255.255.255.0 UG 0 0 0 tun0
192.168.100.0 0.0.0.0 255.255.255.0 U 0 0 0 eth0
what is 192.168.100.0 network?

can you post the output of ifconfig as well?

Michael.

The 192.168.100.0 is an error, and there were two because of an alias on a network interface. I corrected the error, but still not works; after that we removed the "lan to lan" option (when a client exposes the network behind it), but no result. With the ifconfig result, i update the routing tables for Traffic (the other user that asked for tables):

ifconfig
eth0 Link encap:Ethernet HWaddr C8:F9:81:02:01:67
inet addr:192.168.85.106 Bcast:192.168.87.255 Mask:255.255.252.0
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:365127 errors:2 dropped:0 overruns:2 frame:0
TX packets:1049 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:32677683 (31.1 MiB) TX bytes:314815 (307.4 KiB)
Base address:0x8000

eth0:1 Link encap:Ethernet HWaddr C8:F9:81:02:01:67
inet addr:192.168.100.101 Bcast:192.168.100.255 Mask:255.255.255.0
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
Base address:0x8000

lo Link encap:Local Loopback
inet addr:127.0.0.1 Mask:255.0.0.0
UP LOOPBACK RUNNING MTU:16436 Metric:1
RX packets:26 errors:0 dropped:0 overruns:0 frame:0
TX packets:26 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0
RX bytes:1820 (1.7 KiB) TX bytes:1820 (1.7 KiB)

ppp0 Link encap:Point-to-Point Protocol
inet addr:109.53.221.90 P-t-P:10.64.64.64 Mask:255.255.255.255
UP POINTOPOINT RUNNING NOARP MULTICAST MTU:1500 Metric:1
RX packets:2980 errors:0 dropped:0 overruns:0 frame:0
TX packets:2846 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:3
RX bytes:360474 (352.0 KiB) TX bytes:215342 (210.2 KiB)

tun0 Link encap:UNSPEC HWaddr 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00
inet addr:10.9.7.21 P-t-P:10.9.7.22 Mask:255.255.255.255
UP POINTOPOINT RUNNING NOARP MULTICAST MTU:1500 Metric:1
RX packets:0 errors:0 dropped:0 overruns:0 frame:0
TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:100
RX bytes:0 (0.0 B) TX bytes:0 (0.0 B)

route -n
Kernel IP routing table
Destination Gateway Genmask Flags Metric Ref Use Iface
224.1.0.1 0.0.0.0 255.255.255.255 UH 0 0 0 tun0
10.64.64.64 0.0.0.0 255.255.255.255 UH 0 0 0 ppp0
10.9.7.22 0.0.0.0 255.255.255.255 UH 0 0 0 tun0
192.168.100.0 0.0.0.0 255.255.255.0 U 0 0 0 eth0
10.9.7.0 10.9.7.22 255.255.255.0 UG 0 0 0 tun0
192.168.84.0 0.0.0.0 255.255.252.0 U 0 0 0 eth0
0.0.0.0 10.64.64.64 0.0.0.0 UG 0 0 0 ppp0

seneca

We solved the problem by adding this route:

255.255.255.255 0.0.0.0 255.255.255.255 UH 0 0 0 eth0

This takes all broadcast and sends it to the eht0. We would to thank you for all indications that routed us to the solutions.

Best regards.