[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: Wed, 18 Jul 2007 16:59:20 +0400

Hi Erich

Below are the logs, please note that this client (Linux) is in the office (10.0.0.59) while the 217.164.246.54 is my client (Windows XP SP2) at home. It happens right after connecting and sometimes after pinging from client to server.


route -n on server:

Destination     Gateway         Genmask         Flags Metric Ref    Use Iface

10.8.0.2        0.0.0.0         255.255.255.255 UH    0      0        0 tun0

172.16.163.0    0.0.0.0         255.255.255.0   U     0      0        0 vmnet1

10.0.0.0        0.0.0.0         255.255.255.0   U     0      0        0 eth0

10.8.0.0        10.8.0.2        255.255.255.0   UG    0      0        0 tun0

172.16.57.0     0.0.0.0         255.255.255.0   U     0      0        0 vmnet8

169.254.0.0     0.0.0.0         255.255.0.0     U     0      0        0 eth0

127.0.0.0       0.0.0.0         255.0.0.0       U     0      0        0 lo

0.0.0.0         10.0.0.209      0.0.0.0         UG    0      0        0 eth0



openvpn started on server (deleted server name and time stamps):

when starting openvpn:

tail -f /var/log/messages

openvpn[23785]: GID set to nobody

openvpn[23785]: UID set to nobody

openvpn[23785]: UDPv4 link local (bound): [undef]:1194

openvpn[23785]: UDPv4 link remote: [undef]

openvpn[23785]: MULTI: multi_init called, r=256 v=256

openvpn[23785]: IFCONFIG POOL: base=10.8.0.4 size=62

openvpn[23785]: IFCONFIG POOL LIST

openvpn[23785]: petesuse,10.8.0.4

openvpn[23785]: petehome,10.8.0.8

openvpn[23785]: Initialization Sequence Completed


when Linux client connects:


 openvpn[20930]: 10.0.0.59:1068 Data Channel Encrypt: Cipher 'BF-CBC' initialized with 128 bit key

 openvpn[20930]: 10.0.0.59:1068 Data Channel Encrypt: Using 160 bit message hash 'SHA1' for HMAC authentication

 openvpn[20930]: 10.0.0.59:1068 Data Channel Decrypt: Cipher 'BF-CBC' initialized with 128 bit key

 openvpn[20930]: 10.0.0.59:1068 Data Channel Decrypt: Using 160 bit message hash 'SHA1' for HMAC authentication

 openvpn[20930]: 10.0.0.59:1068 Control Channel: TLSv1, cipher TLSv1/SSLv3 DHE-RSA-AES256-SHA, 1024 bit RSA

 openvpn[20930]: 10.0.0.59:1068 [petesuse] Peer Connection Initiated with 10.0.0.59:1068

 openvpn[20930]: petesuse/10.0.0.59:1068 MULTI: Learn: 10.8.0.6 -> petesuse/10.0.0.59:1068

 openvpn[20930]: petesuse/10.0.0.59:1068 MULTI: primary virtual IP for petesuse/10.0.0.59:1068: 10.8.0.6

 openvpn[20930]: petesuse/10.0.0.59:1068 PUSH: Received control message: 'PUSH_REQUEST'

 openvpn[20930]: petesuse/10.0.0.59:1068 SENT CONTROL [petesuse]: 'PUSH_REPLY,route 10.0.0.0 255.255.255.0,redirect-gateway,dhcp-option DNS 10.8.0.1,dhcp-option DNS 10.0.0.25,dhcp-option DNS 10.0.0.114,route 10.8.0.0 255.255.255.0,ping 10,ping-restart 120,ifconfig 10.8.0.6 10.8.0.5' (status=1)

Jul 18 16:41:32 nowsnme openvpn[20930]: petesuse/10.0.0.59:1068 MULTI: bad source address from client [10.0.0.59], packet dropped

openvpn[20930]: petesuse/10.0.0.59:1069 MULTI: bad source address from client [10.0.0.59], packet dropped

last message repeated 7 times



openvpn on client:

Jul 18 16:41:26 pete openvpn[5005]: Control Channel: TLSv1, cipher TLSv1/SSLv3 DHE-RSA-AES256-SHA, 1024 bit RSA

Jul 18 16:41:26 pete openvpn[5005]: [server] Peer Connection Initiated with 10.0.0.114:1194

Jul 18 16:41:27 pete openvpn[5005]: SENT CONTROL [server]: 'PUSH_REQUEST' (status=1)

Jul 18 16:41:27 pete openvpn[5005]: PUSH: Received control message: 'PUSH_REPLY,route 10.0.0.0 255.255.255.0,redirect-gateway,dhcp-option DNS 10.8.0.1,dhcp-option DNS 10.0.0.25,dhcp-option DNS 10.0.0.114,route 10.8.0.0 255.255.255.0,ping 10,ping-restart 120,ifconfig 10.8.0.6 10.8.0.5'

Jul 18 16:41:27 pete openvpn[5005]: OPTIONS IMPORT: timers and/or timeouts modified

Jul 18 16:41:27 pete openvpn[5005]: OPTIONS IMPORT: --ifconfig/up options modified

Jul 18 16:41:27 pete openvpn[5005]: OPTIONS IMPORT: route options modified

Jul 18 16:41:27 pete openvpn[5005]: OPTIONS IMPORT: --ip-win32 and/or --dhcp-option options modified

Jul 18 16:41:27 pete openvpn[5005]: TUN/TAP device tun0 opened

Jul 18 16:41:27 pete openvpn[5005]: /sbin/ifconfig tun0 10.8.0.6 pointopoint 10.8.0.5 mtu 1500

Jul 18 16:41:27 pete openvpn[5005]: /sbin/route add -net 10.0.0.114 netmask 255.255.255.255 gw 10.0.0.209

Jul 18 16:41:27 pete openvpn[5005]: /sbin/route del -net 0.0.0.0 netmask 0.0.0.0

Jul 18 16:41:27 pete openvpn[5005]: /sbin/route add -net 0.0.0.0 netmask 0.0.0.0 gw 10.8.0.5

Jul 18 16:41:27 pete openvpn[5005]: /sbin/route add -net 10.0.0.0 netmask 255.255.255.0 gw 10.8.0.5

Jul 18 16:41:27 pete openvpn[5005]: /sbin/route add -net 10.8.0.0 netmask 255.255.255.0 gw 10.8.0.5

Jul 18 16:41:27 pete openvpn[5005]: GID set to nobody

Jul 18 16:41:27 pete openvpn[5005]: UID set to nobody

Jul 18 16:41:27 pete openvpn[5005]: Initialization Sequence Completed


client routes

pete:/home/pete # route -n

Kernel IP routing table

Destination     Gateway         Genmask         Flags Metric Ref    Use Iface

10.8.0.5        0.0.0.0         255.255.255.255 UH    0      0        0 tun0

10.0.0.114      10.0.0.209      255.255.255.255 UGH   0      0        0 eth0

192.168.54.0    0.0.0.0         255.255.255.0   U     0      0        0 vmnet1

10.0.0.0        10.8.0.5        255.255.255.0   UG    0      0        0 tun0

10.0.0.0        0.0.0.0         255.255.255.0   U     0      0        0 eth0

10.8.0.0        10.8.0.5        255.255.255.0   UG    0      0        0 tun0

192.168.104.0   0.0.0.0         255.255.255.0   U     0      0        0 vmnet8

127.0.0.0       0.0.0.0         255.0.0.0       U     0      0        0 lo


ping from client (10.8.0.6) to server (10.8.0.1):

PING 10.8.0.1 (10.8.0.1) 56(84) bytes of data.

64 bytes from 10.8.0.1: icmp_seq=1 ttl=64 time=0.878 ms

64 bytes from 10.8.0.1: icmp_seq=2 ttl=64 time=0.826 ms

64 bytes from 10.8.0.1: icmp_seq=3 ttl=64 time=0.906 ms

64 bytes from 10.8.0.1: icmp_seq=4 ttl=64 time=0.914 ms

64 bytes from 10.8.0.1: icmp_seq=5 ttl=64 time=3.93 ms

64 bytes from 10.8.0.1: icmp_seq=6 ttl=64 time=1.81 ms

64 bytes from 10.8.0.1: icmp_seq=7 ttl=64 time=0.932 ms


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


Any more info required??


Kind Regards

Peter

>>> Erich Titl <erich.titl@xxxxxxxx> 07/18/07 4:22 PM >>>
Hi Peter

Peter Njiiri wrote:
> Hi Erich,
> Thanks for the feedback, it's only when I use/enable the
> redirect-gateway option.

OK, I have no definite answer, but this has shown up a few times, so
let's try to sort it out.

As you can reproduce your problem, can you report line traffic, routing
tables,.... etc. possibly show the incriminating packet?

cheers

Erich