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
--
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive:
https://lists.debian.org/89d1798a7351d040b4e74e0a043c69d7ea72c...@einexch-01.tio.nl
