MULTI: bad source address from client[::], packetd dropped

Scripts with setup, destroy, and modify routing tables and firewall rulesets for client connections.

Moderators: TinCanTech, TinCanTech, TinCanTech, TinCanTech, TinCanTech, TinCanTech

Post Reply
kelvin22
OpenVpn Newbie
Posts: 3
Joined: Sat Jan 16, 2016 11:09 pm

MULTI: bad source address from client[::], packetd dropped

Post by kelvin22 » Sun Jan 17, 2016 9:56 am

Been banging my head for 2 days now with this error.

server.conf

local <external ip>
port 443

proto tcp

dev tun

ca /root/vpn/ca.crt
cert /root/vpn/srv.crt
key /root/vpn/srv.key
dh /root/vpn/dh.pem

server 10.77.198.0 255.255.255.0

ifconfig-pool-persist ipp.txt
client-config-dir cust-client-cfg

#need to access 169.254.0.0 subnet
push "route 169.254.0.0 255.255.0.0"
#redirect traffic
push "redirect-gateway def1"
#set DNS
push "dhcp-options DNS 10.77.198.2"

#don't enbable unless u want clients to see each other
#client-to-client

keepalive 10 120

tls-auth /root/vpn/hmac.key 0
comp-lzo
max-clients 10

plugin /usr/lib64/openvpn/openvpn-plugin-auth-pam.so openvpn login USERNAME password PASSWORD

cipher AES-256-CBC
auth SHA512
keysize 256

user nobody
group nobody

persist-key
persist-tun

status /var/log/openvpn-status.log
log /var/log/openvpn.log
log-append /var/log/openvpn.log
verb 4


################
client.ovpn (connection via OpenVPN GUI on Windows)

setenv FORWARD_COMPATIBLE 1
client
proto tcp
remote <server ip>
port 443
dev tun
dev-type tun
ns-cert-type server
reneg-sec 604800
sndbuf 100000
rcvbuf 100000
auth-user-pass
comp-lzo
verb 3
setenv PUSH_PEER_INFO
cipher AES-256-CBC
auth SHA512
keysize 256
<ca>
-----BEGIN CERTIFICATE-----
***
-----END CERTIFICATE-----
</ca>

<cert>
-----BEGIN CERTIFICATE-----
***
-----END CERTIFICATE-----
</cert>

<key>
-----BEGIN PRIVATE KEY-----
***
-----END PRIVATE KEY-----
</key>

key-direction 1
<tls-auth>
#
# 2048 bit OpenVPN static key (Server Agent)
#
-----BEGIN OpenVPN Static key V1-----
***
-----END OpenVPN Static key V1-----
</tls-auth>


ifconfig output

eno1 is external ip

eno2: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500
inet 169.254.55.223 netmask 255.255.0.0 broadcast 169.254.255.255

lo: flags=73<UP,LOOPBACK,RUNNING> mtu 65536
inet 127.0.0.1 netmask 255.0.0.0

tun0: flags=4305<UP,POINTOPOINT,RUNNING,NOARP,MULTICAST> mtu 1500
inet 10.77.198.1 netmask 255.255.255.255 destination 10.77.198.2

iptables -L -t nat -v

Chain PREROUTING (policy ACCEPT 27 packets, 5234 bytes)
pkts bytes target prot opt in out source destination

Chain INPUT (policy ACCEPT 27 packets, 5234 bytes)
pkts bytes target prot opt in out source destination

Chain OUTPUT (policy ACCEPT 14 packets, 942 bytes)
pkts bytes target prot opt in out source destination

Chain POSTROUTING (policy ACCEPT 14 packets, 942 bytes)
pkts bytes target prot opt in out source destination

log output

Data Channel Encrypt: Cipher 'AES-256-CBC' initialized with 256 bit key
<remote ip>:54549 Data Channel Encrypt: Using 512 bit message hash 'SHA512' for HMAC authentication
<remote ip>:54549 Data Channel Decrypt: Cipher 'AES-256-CBC' initialized with 256 bit key
<remote ip>:54549 Data Channel Decrypt: Using 512 bit message hash 'SHA512' for HMAC authentication
<remote ip>:54549 Control Channel: TLSv1.2, cipher TLSv1/SSLv3 DHE-RSA-AES256-GCM-SHA384, 2048 bit RSA
<remote ip>:54549 [master] Peer Connection Initiated with [AF_INET]<remote ip>:54549
master/<remote ip>:54549 OPTIONS IMPORT: reading client specific options from: cust-client-cfg/master
master/<remote ip>:54549 MULTI: Learn: 10.77.198.10 -> master/<remote ip>:54549
master/<remote ip>:54549 MULTI: primary virtual IP for master/<remote ip>:54549: 10.77.198.10
master/<remote ip>:54549 PUSH: Received control message: 'PUSH_REQUEST'
master/<remote ip>:54549 send_push_reply(): safe_cap=940
master/<remote ip>:54549 SENT CONTROL [master]: 'PUSH_REPLY,route 169.254.0.0 255.255.0.0,redirect-gateway def1,dhcp-options DNS 10.77.198.2,route 10.77.198.1,topology net30,ping 10,ping-restart 120,ifconfig 10.77.198.10 10.77.198.9' (status=1)
master/<remote ip>:54549 MULTI: bad source address from client [::], packet dropped

I seem to able to connect, auth is passed... ip is assigned on client side, but i can't seem to be able to route traffic through the vpn.
Can someone post a set of iptables rules that properly route packets between my interfaces?

User avatar
Traffic
OpenVPN Protagonist
Posts: 4066
Joined: Sat Aug 09, 2014 11:24 am

Re: MULTI: bad source address from client[::], packetd dropp

Post by Traffic » Sun Jan 17, 2016 11:36 am

kelvin22 wrote:#need to access 169.254.0.0 subnet
push "route 169.254.0.0 255.255.0.0"
You cannot access network 169.254.0.0/16 as it is a fall back address reserved for DHCP and is unroutable. What you need is to properly assign an IP address, either statically or by configuring a DHCP server.
Re: MULTI: bad source address from client[::], packetd dropp
This is caused by:
https://community.openvpn.net/openvpn/w ... rt-failedq

In your case, this is IPv6 packet and you need to configure your server with IPv6 or you can safely ignore it.

Using IPv6 in OpenVPN:
https://community.openvpn.net/openvpn/wiki/IPv6

This will also help you understand:
HOWTO: Expanding the scope of the VPN to include additional machines

kelvin22
OpenVpn Newbie
Posts: 3
Joined: Sat Jan 16, 2016 11:09 pm

Re: MULTI: bad source address from client[::], packetd dropp

Post by kelvin22 » Sun Jan 17, 2016 12:25 pm

ok, so openvpn docs say

For the purpose of this example, we will assume that the server-side LAN uses a subnet of 10.66.0.0/24 and the VPN IP address pool uses 10.8.0.0/24 as cited in the server directive in the OpenVPN server configuration file.

First, you must advertise the 10.66.0.0/24 subnet to VPN clients as being accessible through the VPN. This can easily be done with the following server-side config file directive:

push "route 10.66.0.0 255.255.255.0"

169.254.0.0 255.255.0.0 is an internal subnet to which the server is linked. The ip on this subnet is assigned by a dhcp server.

Regardless...

Say i don't want to necessarily access 169.254 subnet, so, i comment out that line, but i'm still getting the same error.

Plus... bad source address from client[::], packet dropped... Shouldn't there be an ip address between [], mainly the one assigned to the client. On my windows machine the client IS being assigned an ip.

What am i missing?

User avatar
Traffic
OpenVPN Protagonist
Posts: 4066
Joined: Sat Aug 09, 2014 11:24 am

Re: MULTI: bad source address from client[::], packetd dropp

Post by Traffic » Sun Jan 17, 2016 12:35 pm

kelvin22 wrote:169.254.0.0 255.255.0.0 is an internal subnet to which the server is linked. The ip on this subnet is assigned by a dhcp server.
Incorrect. You have failed to obtain an IP address from your DHCP server.

kelvin22
OpenVpn Newbie
Posts: 3
Joined: Sat Jan 16, 2016 11:09 pm

Re: MULTI: bad source address from client[::], packetd dropp

Post by kelvin22 » Sun Jan 17, 2016 1:56 pm

Traffic wrote:
kelvin22 wrote:169.254.0.0 255.255.0.0 is an internal subnet to which the server is linked. The ip on this subnet is assigned by a dhcp server.
Incorrect. You have failed to obtain an IP address from your DHCP server.
eno2: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500
inet 169.254.55.223 netmask 255.255.0.0 broadcast 169.254.255.255
inet6 fe80::226:2dff:fe0c:377d prefixlen 64 scopeid 0x20<link>
ether 00:26:2d:0c:37:7d txqueuelen 1000 (Ethernet)
RX packets 348924 bytes 21001538 (20.0 MiB)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 267 bytes 8936 (8.7 KiB)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0
device memory 0xfb900000-fb91ffff

eno2 is on a vlan and is accessible from my other servers.

Anyway, i'm not pushing the route any more. Just wanna make it work first, and be able to route traffic between eno1 and tun0.

User avatar
Traffic
OpenVPN Protagonist
Posts: 4066
Joined: Sat Aug 09, 2014 11:24 am

Re: MULTI: bad source address from client[::], packetd dropp

Post by Traffic » Sun Jan 17, 2016 2:08 pm

kelvin22 wrote:eno2 is on a vlan and is accessible from my other servers
If you do not configure your network properly then expect it not to work properly:
http://packetlife.net/blog/2008/sep/24/ ... explained/
kelvin22 wrote:Anyway, i'm not pushing the route any more. Just wanna make it work first, and be able to route traffic between eno1 and tun0.
OK: The link I posted before shows you the required iptables NAT command.

In your case it may be necessary to use this instead:

Code: Select all

iptables -t nat -A POSTROUTING -s 10.77.198.0/24 -j SNAT --to-source Real.Server.public.ip.address

Post Reply