[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: Thu, 19 Jul 2007 12:55:36 +0400

Hi Erich,

Thanks for the feedback. Normally the iroute/-client-config-dir is used for client machine which is being used as a gateway. However my machines are just road warriors connecting the the VPN without needing to advertise the network they are on. When adding the iroute and routes, it seems I've to add the network instead of the hosts?Is there a way in which no matter from which location/IP I connect from these errors don't come up??If not, then can I just add the host IP instead of the network in the iroute or route definitions???


Kind Regards

Peter

>>> Erich Titl <erich.titl@xxxxxxxx> 07/18/07 9:46 PM >>>
Peter

Peter Njiiri schrieb:
> Sorry, this is the new IP leased from the ISP  to my home computer,still the same client. So are there routes to add or server.conf statements to edit??
>
> Kind Regards
> Peter
>
>>>> Erich Titl <erich.titl@xxxxxxxx>  >>>
> Peter
>
> Peter Njiiri wrote:
>> Hi Erich,
>> After disabling the option to push the 10.0.0.0 route, the error still comes up after openvpn startup on server and Windows home client.
>
> Yes, but this may be for a different reason, what about the office client?
>
>> Jul 18 18:47:33 nowsnme openvpn[8474]: 86.99.192.38:1690 Data Channel Encrypt: Cipher 'BF-CBC' initialized with 128 bit key
>> Jul 18 18:47:33 nowsnme openvpn[8474]: 86.99.192.38:1690 Data Channel Encrypt: Using 160 bit message hash 'SHA1' for HMAC authentication
>> Jul 18 18:47:33 nowsnme openvpn[8474]: 86.99.192.38:1690 Data Channel Decrypt: Cipher 'BF-CBC' initialized with 128 bit key
>> Jul 18 18:47:33 nowsnme openvpn[8474]: 86.99.192.38:1690 Data Channel Decrypt: Using 160 bit message hash 'SHA1' for HMAC authentication
>> Jul 18 18:47:33 nowsnme openvpn[8474]: 86.99.192.38:1690 Control Channel: TLSv1, cipher TLSv1/SSLv3 DHE-RSA-AES256-SHA, 1024 bit RSA
>> Jul 18 18:47:33 nowsnme openvpn[8474]: 86.99.192.38:1690 [petehome] Peer Connection Initiated with 86.99.192.38:1690
>> Jul 18 18:47:33 nowsnme openvpn[8474]: petehome/86.99.192.38:1690 MULTI: Learn: 10.8.0.10 -> petehome/86.99.192.38:1690
>> Jul 18 18:47:33 nowsnme openvpn[8474]: petehome/86.99.192.38:1690 MULTI: primary virtual IP for petehome/86.99.192.38:1690: 10.8.0.10
>> Jul 18 18:47:34 nowsnme openvpn[8474]: petehome/86.99.192.38:1690 PUSH: Received control message: 'PUSH_REQUEST'
>> Jul 18 18:47:34 nowsnme openvpn[8474]: petehome/86.99.192.38:1690 SENT CONTROL [petehome]:


'PUSH_REPLY,
redirect-gateway,  >>>> OK
route 10.8.0.0 255.255.255.0, >>>>>>>> OK this is done by --server
10.8.0.0 255.255.255.0 _and_ client-to-client
ping 10,ping-restart 120, >>>>> OK
ifconfig 10.8.0.10 10.8.0.9' (status=1) >>>> this looks good also

>> Jul 18 18:47:41 nowsnme openvpn[8474]: petehome/86.99.192.38:1690 MULTI: bad source address from client [86.99.192.38], packet dropped
>> Jul 18 18:47:51 nowsnme last message repeated 8 times

In multi.c it is checked if the source address of the packet is
associated with a certain client instance, if it does not match, then
the packet is discarded

googling for the error revealed a reply from James Yonan which may be of
interest

On Sun, 9 Jan 2005, Markku Leinio wrote:

> Hi folks. I have been using dev tap with my VPN very successfully a
couple
> of months but have now been testing dev tun instead. Everything is great
> otherwise, but I get the following messages in the log in the server side:
>
> Sun Jan  9 18:10:41 2005 Markku_Leinio/193.166.XXX.XXX:1663 MULTI: bad
> source address from client [10.YYY.YYY.YYY], packet dropped

That error occurs when OpenVPN gets a packet from a client for which it
has no return route back to the client.  It's a security feature that
prevents other machines on the client LAN from using the VPN unless they
are explicity allowed to.  --dev tap mode is more permissive (because of
the semantics of ethernet bridging) and does not enforce any source
address checking unless you use a --learn-address script.

To explicitly allow packets from 10.YYY.YYY.YYY, you need to use
--iroute/-client-config-dir.

Maybe this helps

Erich