[OpenVPN home] [Date Prev] [Date Index] [Date Next]
[OpenVPN mailing lists] [Thread Prev] [Thread Index] [Thread Next]
Google
 
Web openvpn.net

Re: [Openvpn-users] MULTI: bad source address from client [217.164.246.54], packet dropped


  • Subject: Re: [Openvpn-users] MULTI: bad source address from client [217.164.246.54], packet dropped
  • From: "Peter Njiiri" <pnjiiri@xxxxxxxxx>
  • Date: Mon, 23 Jul 2007 11:24:14 +0400

Hi Erich,
Below is the tcpdump,I believe that the source address can be seen as shown below. I tried doing an ethernet bridging and though connection was successful, I couldn't ping the physical nic or tap0 interface between the client and server and vice versa after starting bridge-start and starting openvpn. I configured bridge-start with the physical nic for eth settings while I added/modified the following settings in the server.conf:
 
dev tap
server-bridge 10.0.0.114 255.255.255.0 10.0.0.140 10.0.0.150
<disabled server 10.8.0.0 255.255.255.0>
 
I tried replacing the IP with the gateway IP in the server-bridge statement but still no success. All other settings remain the same i.e redirect-gateway, push route 10.0.0.0, push dhcp-options etc.
 
I think I will now have to ignore the MULTI: bad source address from client [217.164.246.54], packet dropped error as the VPN seems to work as it's able to redirect everything through the VPN.
 
<<<<<tcpdump on server and client on tun0 interface>>>>>>>>>>>>>
 
received ping on server (tun0=10.8.0.1):
tcpdump -i tun0
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on tun0, link-type LINUX_SLL (Linux cooked), capture size 96 bytes
16:48:03.194817 IP 10.8.0.6 > 10.8.0.1: icmp 64: echo request seq 1
16:48:03.194888 IP 10.8.0.1 > 10.8.0.6: icmp 64: echo reply seq 1
16:48:04.193722 IP 10.8.0.6 > 10.8.0.1: icmp 64: echo request seq 2
16:48:04.193791 IP 10.8.0.1 > 10.8.0.6: icmp 64: echo reply seq 2
16:48:05.192896 IP 10.8.0.6 > 10.8.0.1: icmp 64: echo request seq 3
16:48:05.192963 IP 10.8.0.1 > 10.8.0.6: icmp 64: echo reply seq 3
 
ping from server to client (tun0=10.8.0.6):
 
ping 10.8.0.6
PING 10.8.0.6 (10.8.0.6) 56(84) bytes of data.
64 bytes from 10.8.0.6: icmp_seq=1 ttl=64 time=0.871 ms
64 bytes from 10.8.0.6: icmp_seq=2 ttl=64 time=0.803 ms
64 bytes from 10.8.0.6: icmp_seq=3 ttl=64 time=0.841 ms
64 bytes from 10.8.0.6: icmp_seq=4 ttl=64 time=1.08 ms
64 bytes from 10.8.0.6: icmp_seq=5 ttl=64 time=1.45 ms
64 bytes from 10.8.0.6: icmp_seq=6 ttl=64 time=0.802 ms  
 
tcpdump on client on tun0:
 
16:51:40.919571 IP 10.8.0.1 > 10.8.0.6: ICMP echo request, id 8794, seq 42, length 64
16:51:40.919639 IP 10.8.0.6 > 10.8.0.1: ICMP echo reply, id 8794, seq 42, length 64
16:51:41.921403 IP 10.8.0.1 > 10.8.0.6: ICMP echo request, id 8794, seq 43, length 64
16:51:41.921441 IP 10.8.0.6 > 10.8.0.1: ICMP echo reply, id 8794, seq 43, length 64
16:51:42.921363 IP 10.8.0.1 > 10.8.0.6: ICMP echo request, id 8794, seq 44, length 64
16:51:42.921421 IP 10.8.0.6 > 10.8.0.1: ICMP echo reply, id 8794, seq 44, length 64
Kind Regards
Peter

>>> Erich Titl <erich.titl@xxxxxxxx> 19/07/2007 17:05 >>>
Peter

Peter Njiiri wrote:
>
>
> Erich,
>
> Ok, how can I find out if the packet doesn't have the source address and
> is it possible to troubleshoot it?

Tcpdump the tunnel interface.

cheers

Erich