|
|
On 4.6.2005 0:00, James Yonan wrote: > This can occur if you get a routing loop -- in such a case the CPU goes to > 100% because OpenVPN is receiving a flood of packets to push through the > tunnel, and so is spending a lot of cycles to encrypt/decrypt them. Oh, there really is a routing issue: >>push "route <vpn-server-ip> 255.255.255.255 net_gateway" >>push "route <first-network> 255.255.255.0 default 100" This first-network actually contains the vpn-server-ip, that's why I have to enter a /32 route before the first-network. So, when the network goes down, the route to vpn-server-ip disappears and OpenVPN tries to reach the vpn-server-ip through the tunnel, which causes OpenVPN to send the packets to itself, I guess. Ethereal dump showed only UDP packets going from the local tunnel endpoint (private) address to the server public address. I don't see any other way to prevent this but specifying n+1 smaller routes to cover all other addresses from the /24 than the single vpn-server-ip, so I will just live with this. Thanks for your comments. -- Markku Leiniö, Turku, Finland |