OpenVPN Support Forum

Please read this message thoroughly as my problem does not match up with the standard scenario that the majority of internet solutions address:

My setup is this: Company Network -> OpenVPN Server -> ~INTERNET~ -> (Possibly a home router) -> Client

I am not bridging two networks or anything complicated like that, all we need is for employees to be able to access the company network from home. The problem occurs when users connect to the VPN from behind a router of some sort. For some reason, OpenVPN receives their private IP address instead of the Router's IP address as the source address, I guess because of the VPN encapsulation. The odd thing is, their connection still works...however, in the log files I see multiple instances of MULTI: bad source address from client....packet dropped. We cannot use CCD files primarily because we have no way of knowing what the private networks will be for all our users but also because we use the Topology option and currently CCD files do not work with it.

Please read viewtopic.php?f=8&t=98
You only need to use ccd entries for the client lans which need to be shared by the VPN.
An OpenVPN server has an internal routing table (configured via iroute). This is needed because the kernel routing table can only point to OpenVPN, not to specific clients. When a client transmits packets to the server with a source address in a subnet that the internal routing table does not know about, the packets are dropped at that MULTI error is printed.
Check the MULTI errors for exactly what LAN ip is being dropped, odds are it is not the same machine that openvpn is running on.
When you do want the client LAN shared, you use route/push route/iroute in a ccd entry.
When you do not want the client LAN shared, you will get MULTI errors when a machine in that LAN tries to communicate over the VPN. If possible you can stop the client from forwarding any traffic by disabling ip forwarding on the vpn node.

Thanks for the reply!

The reason I mentioned CCD files is due to other solutions I have read where people wanted their private networks to be accessible over the VPN, something I don't want in this case.

I know what IP address are being dropped, it's the private networks of whoever happens to be connected at the time and I know why, because of the routing tables. What I didn't know was how to stop those packets from traversing the VPN. It's happening because we force all traffic down the tunnel to keep people from browsing the web and such while connected to the VPN.

How exactly do you stop the client from forwarding just local traffic while still forcing all other traffic (ie, HTTP, FTP, etc) to traverse the tunnel?

hypercoyote wrote: How exactly do you stop the client from forwarding just local traffic while still forcing all other traffic (ie, HTTP, FTP, etc) to traverse the tunnel?

The traffic you do not want going over the VPN needs a more specific route pointing elsewhere