open vpn client uses wrong address sometimes
Hi,
I need to find out why a plain Debian Wheezy install (fully patched) acting as firewall router on a remote location sends packets with the wrong address into the openvpn tunnel.
OpenVPN server sided log states:
Thu Jul 16 09:23:19 2015 us=237261 m.duthler-lan/82.217.xxx.xxx:52126 MULTI: bad source address from client [192.168.178.5], packet dropped
Thu Jul 16 09:23:19 2015 us=917448 m.duthler-lan/82.217.xxx.xxx:52126 MULTI: bad source address from client [192.168.178.5], packet dropped
So, the client is sending packets using its eth1 address
It needs to use its eth0 address for anything going to the rest of the 172.16.0.0/16 network
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 16436 qdisc noqueue state UNKNOWN
[...]
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP qlen 1000
link/ether 00:11:6b:99:34:90 brd ff:ff:ff:ff:ff:ff
inet 172.16.18.1/24 brd 172.16.18.255 scope global eth0
inet6 fd00::1:211:6bff:fe99:3490/64 scope global dynamic
valid_lft 6266sec preferred_lft 6266sec
inet6 fe80::211:6bff:fe99:3490/64 scope link
valid_lft forever preferred_lft forever
3: eth1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP qlen 1000
link/ether b8:ac:6f:a0:24:a1 brd ff:ff:ff:ff:ff:ff
inet 192.168.178.5/24 brd 192.168.178.255 scope global eth1
inet6 fe80::baac:6fff:fea0:24a1/64 scope link
valid_lft forever preferred_lft forever
4: tun0: <POINTOPOINT,MULTICAST,NOARP,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UNKNOWN qlen 100
link/none
inet 172.16.1.142 peer 172.16.1.141/32 scope global tun0
Trying to find out what these packets are I added an iptables rule on the client machine:
Chain OUTPUT (policy ACCEPT 80564 packets, 13M bytes)
pkts bytes target prot opt in out source destination
0 0 LOG all -- * tun0 192.168.178.0/24 0.0.0.0/0 limit: avg 3/hour burst 5 LOG flags 0 level 4
Stragely enough, while the openvpn log keeps logging packets coming from the client, the iptables rule on the client logs nothing, no initial packets before hitting the limit, just nothing.
If it is coming from the local address 192.168.178.5 then it must come through the OUTPUT chain, right?
Ok, so I added a LOG line to FORWARD as well, just to be on the safe side
Chain FORWARD (policy DROP 0 packets, 0 bytes)
pkts bytes target prot opt in out source destination
10677 1365K ACCEPT all -- * * 0.0.0.0/0 0.0.0.0/0 state RELATED,ESTABLISHED
0 0 LOG all -- * tun0 192.168.178.0/24 0.0.0.0/0 limit: avg 3/hour burst 5 LOG flags 0 level 4
[...]
Still no result while the OpenVPN log on the server keeps logging those lines about 192.168.178.5
There is only 1 line in the nat table
# iptables -t nat -L -v -n
[...]
Chain POSTROUTING (policy ACCEPT 19 packets, 1176 bytes)
pkts bytes target prot opt in out source destination
598 61508 MASQUERADE all -- * eth1 0.0.0.0/0 0.0.0.0/0
Pretty much standard for local traffic leaving for the internet.
In case it is relevant, client sided routing table is:
default via 192.168.178.1 dev eth1
172.16.0.0/16 via 172.16.1.141 dev tun0
172.16.1.129 via 172.16.1.141 dev tun0
172.16.1.141 dev tun0 proto kernel scope link src 172.16.1.142
172.16.18.0/24 dev eth0 proto kernel scope link src 172.16.18.1
192.168.178.0/24 dev eth1 proto kernel scope link src 192.168.178.5
I have no problem reaching any system on the other side using ping.
I can do a dig and it will use our company dns server and produce the proper result.
How can I debug this problem further?
Bonno Bloksma
Reply to: