OpenVPN bad source address from client

Question

I have one problem with OpenVPN. There are a lot drops records in the openvpn log file on the server:

Mon Oct 22 10:14:41 2012 us=726541 laptop/ххх:1194 MULTI: bad source address from client [192.168.1.107], packet dropped

grep -E "^[a-z]" server.conf  
-----
port 1194  
proto udp
dev tun 
ca data/ca.crt 
cert data/server.crt
key data/server.key 
dh data/dh1024.pem 
tls-server
tls-auth data/ta.key 0
remote-cert-tls client 
cipher AES-256-CBC
tun-mtu 1200
server 10.10.10.0 255.255.255.0 
ifconfig-pool-persist ipp.txt
push "redirect-gateway def1 bypass-dhcp"
push "dhcp-option DNS 8.8.8.8"
client-to-client
client-config-dir /etc/openvpn/ccd
route 10.10.10.0 255.255.255.0
keepalive 10 120
comp-lzo
persist-key
persist-tun
max-clients 5
status /var/log/status-openvpn.log
log  /var/log/openvpn.log
verb 4
auth-user-pass-verify /etc/openvpn/verify.sh via-file
tmp-dir /tmp
script-security 2
-----

cat ccd/laptop
-----
iroute 10.10.10.0 255.255.255.0
-----

cat client.conf 
-----
remote server ip 1194
client
dev tun
ping 10

comp-lzo
proto udp
tls-client
tls-auth data/ta.key 1
pkcs12 data/vpn.laptop.p12

remote-cert-tls server
#ns-cert-type server
persist-key
persist-tun
cipher AES-256-CBC

verb 3
pull

auth-user-pass /home/user/.openvpn/users.db 
-----

According to "Jan Just Keijser - OpenVPN 2 Cookbook" root of the problem is incorrect config options.see the screenshot

But, as you see, my config has such options. Could you please help me to solve this problem.

@week Verb leverl=6;

client log.
Mon Oct 22 16:06:02 2012 do_ifconfig, tt->ipv6=0, tt->did_ifconfig_ipv6_setup=0
Mon Oct 22 16:06:02 2012 /sbin/ifconfig tun0 10.10.10.3 pointopoint 10.10.10.5 mtu 1500
Mon Oct 22 16:06:02 2012 /sbin/route add -net xxxx netmask 255.255.255.255 gw 192.168.1.1
Mon Oct 22 16:06:02 2012 /sbin/route add -net 0.0.0.0 netmask 128.0.0.0 gw 10.10.10.5
Mon Oct 22 16:06:02 2012 /sbin/route add -net 128.0.0.0 netmask 128.0.0.0 gw 10.10.10.5
Mon Oct 22 16:06:02 2012 Initialization Sequence Completed

cat ccd/latop
iroute 10.10.10.0 255.255.255.0 ifconfig-push 10.10.10.3 10.10.10.5

Solution 1

You are specifying client-config-dir which in turn would control the subnet routes added for connected clients and the subnets allowed to transport data over the tun interface. Your CCD file specifies an iroute to 10.10.10.0/24 which obviously does not include 192.168.1.107, so a packet with this source IP address coming from laptop is dropped on reception.

Solution 2

Are you certain about that hostname laptop, try to add DEFAULT config file to ccd dir. I would also try checking access rights to dir and files within ccd.

Comments

[Klesk]

vpn.laptop.p12 has CN = laptop, rights on the openvpn config dir and all files are 777

[week]

Did you try more verb level on both client and server? If client is receiving that config iroute?

[Klesk]

Thank you for a good explanation. But how I can fix this problem?

[the-wabbit]

@Bogdan obviously by either adding the 192.168.1.0/24 subnet as an iroute to your CCD or stopping sending from the 192.168.1.0/24 network as the source address (e.g. by masquerading your traffic going through the VPN at the OpenVPN client to the address of its tun interface)

[Klesk]

Is this message critical ?

[the-wabbit]

@Bogdan the message is telling you that a host with the IP address 192.168.1.107 has tried sending packets through the VPN via your connected "laptop" OpenVPN client. The OpenVPN gateway has discarded this packet. Whether this is critical or not is entirely up to your requirements.

[TomG]

I have this message, too. It seems more like a client issue -- the server should never see packets with a source of 192.168.x.x, as the address assigned to the client end of the tunnel is in the 10.11.0/24 network.

[the-wabbit]

@TomG the client would route anything into the tunnel according to its routing tables. It would not do any checking for the validity of source IP addresses. As checking would happen at the server side by default, there would not be any point to do so.

[TomG]

@syneticon-dj In my case, the client is sending packets with a source address of its own local address, which could be a cellular network, or the WiFi in a coffee shop. I don't know why this would ever be expected, but maybe I'm missing something.