Re: open vpn client uses wrong address sometimes
On Thu, Jul 16, 2015, at 05:19, Bonno Bloksma wrote:
> 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.
>
> 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
>
> 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
Just to get this straight: the Debian Wheezy box is both the firewall
router and the OpenVPN client? So it is routing traffic as follows:
----------------------
|Firewalled machine A|>
| 172.16.18.2/24 | > ----------------- -----------------
---------------------- >| Debian Wheezy | |OpenVPN Server |
|172.16.18.1/24 | (OpenVPN) |172.16.?.?/16 |
---------------------- >|172.16.1.142/32| >>>>>>>>> |172.16.1.141/32|
|Firewalled machine B| > ----------------- -----------------
| 172.16.18.3/24 |> ___ _ v
---------------------- ( ) )___ _v
( ) )_____
( Intranet (a "cloud")
( 172.16.0.0/16 )
-----------------------
I've ignored the physical Internet, to which the Debian Wheezy machine
is attached through its 192.168.168.5 interface and over which the
OpenVPN traffic travels.
Have you read this relevant part of the OpenVPN HOWTO?
https://openvpn.net/index.php/open-source/documentation/howto.html#scope
On Thu, Jul 16, 2015, at 05:19, Bonno Bloksma wrote:
> 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
Do these log messages appear when you:
- ping some host on 172.16.0.0/16 from Firewalled Machine A?
- ping debian.org from Firewalled Machine A?
- ping some host on 172.16.0.0/16 from the Debian Wheezy machine?
- ping debian.org from the Debian Wheezy machine?
- ping the remote endpoint 172.16.1.141 from Debian Wheezy?
- some combination of the above?
On Thu, Jul 16, 2015, at 05:19, Bonno Bloksma wrote:
> 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)
> target prot out source destination
> destination
> LOG all tun0 192.168.178.0/24 0.0.0.0/0
>
> Stragely enough, while the openvpn log keeps logging packets coming from
> the client, the iptables rule on the client logs nothing...
> If it is coming from the local address 192.168.178.5 then it must come
> through the OUTPUT chain, right?
The OUTPUT chain is only traversed by packets which originate from a
local process, and the fact that no logs are being generated by this
rule implies that the 192.168.178.5 packets are not coming directly from
the Debian Wheezy machine.
On Thu, Jul 16, 2015, at 05:19, Bonno Bloksma wrote:
> 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)
> target out source destination
> ACCEPT -- 0.0.0.0/0 0.0.0.0/0 state RELATED,ESTABLISHED
> LOG 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
I think you were on the right track here. The trouble is that ACCEPT is
a terminating target, so that once a packet has been ACCEPT'ed, it isn't
matched against any further rules in the chain. Try this instead:
iptables -I FORWARD 1 -j LOG -o tun0 -s 192.168.178.0/24 -m limit
That might still not work, because the POSTROUTING chain in the nat
table might be responsible for the 192.168.178.5 address. But try it
anyway!
On Thu, Jul 16, 2015, at 05:19, Bonno Bloksma wrote:
> There is only 1 line in the nat table
> # iptables -t nat -L -v -n
> [...]
> Chain POSTROUTING (policy ACCEPT 19 packets, 1176 bytes)
> target prot opt in out source destination
> MASQUERADE all -- * eth1 0.0.0.0/0 0.0.0.0/0
> Pretty much standard for local traffic leaving for the internet.
I'd recommend adding a LOG rule to POSTROUTING, but unfortunately that
won't work. You can't LOG packets which have already jumped to the
MASQUERADE target. We could LOG before the MASQUERADE, but that's not
particularly helpful because those packets will look just like they did
at the end of the FORWARD/OUTPUT chains (i.e., without modifications to
the source address).
On Thu, Jul 16, 2015, at 05:19, Bonno Bloksma wrote:
> How can I debug this problem further?
One thing you can try is running tcpdump on tun0 on the client-side.
That should show you the packets which are supposedly being sent from
192.168.178.5.
Reply to: