|
|
> > Why? there are some timeout? it centers something with "--reneg-sec" > > argoument??? --reneg-sec n tells OpenVPN to randomly generate new keys every n seconds. It's not a timeout. However, --reneg-sec n guarantees that even if the tunnel is idle for a long time, there will be traffic over it at least every n seconds, since every key renegotiation causes a few packets to be sent in both directions. So if this is a stateful firewall timeout issue as Alberto insightfully suggests below, one way of fixing the problem would be to make n smaller than the firewall timeout. This would cause OpenVPN's periodic key renegotiation to keep the stateful firewall rule alive. > The firewall in front of pc1 is a Stateful firewall, isn't it? Probably > iptables. The problem is that your firewall will let packets trough only > if it knows those packets belong to a connection. > If you start sending packets from pc1 then packets from pc2 are supposed > to be from the same 'connection' (ok, UDP has no connections, but just > to ilustrate my example :-) > > So when time passes, and there's no traffic, if pc2 tries to send > anything to pc1, the firewall won't associate those packets with > anything 'going on' and it won't let them pass. Another solution to the problem is to put explicit rules in your iptables setup to allow the incoming OpenVPN UDP packets, for example iptables -A INPUT -p udp -s 1.2.3.4 --dport 8000 -j ACCEPT will allow incoming UDP packets on port 8000 from host 1.2.3.4. You would run this command on both peers with the 1.2.3.4 changed to the actual address of the other peer. James _______________________________________________ Openvpn-users mailing list Openvpn-users@xxxxxxxxxxxxxxxxxxxxx https://lists.sourceforge.net/lists/listinfo/openvpn-users |