On 07/17/2013 10:46 AM, Ståle Johnsen wrote: > Hi, > We have a issue where 2 clients behind a nat router are not able to > connect to an remote openvpn server. One client works but as soon as the > second client connect, the first one disconnects. > > The server logs are showing multiple entries of this: > > TLS Auth Error: TLS object CN attempted to change from 'client1' to > 'client2' -- tunnel disabled > > So it looks like the OpenVPN server detects the two different clients as > the same one trying to change certificates, so it goes into a blocking > state (tunnel disabled). > > As far as I understand a client is identified by the public ip and > source port so I found this interesting: > > 1.2.3.4 <http://1.2.3.4>:*1194* [client1] Peer Connection Initiated with > 1.2.3.4:*1194* > 1.2.3.4:*1194* [client2] Peer Connection Initiated with 1.2.3.4:*1194* > > Why are both clients connecting with 1194 as source port? Shouldn't this > be a random port? I guess this is why the openvpn server thinks it is > the same client.
How your router chooses to translate ports is up to its configuration and design; some NATs attempt not to change ports unless they need to, such as when a 2nd client is using the same source port as an existing connection and thus must be changed. Looks like your NAT is screwing up if the first connection is still being tracked by the NAT system itself. It's also possible that the first connection got dropped from the NAT's view if you're not using a low-enough --ping value (see the manpage description for --keepalive, which is a wrapper for --ping and --ping-timeout.) Note that many OSes have a fairly low timeout for "established" UDP flows (the Linux kernel defaults to 180 seconds, for instance.) > I tried to connect with client1 certificate from another computer and > router and the port was random on connection: > > 5.6.7.8 <http://5.6.7.8>:*51457* [client1] Peer Connection Initiated > with 5.6.7.8 <http://5.6.7.8>:*51457* > > So is there some config issue on the clients behind router 1.2.3.4 > causing them to not use random ports, or is it a router nat issue ? The clients themselves won't use random ports unless they're told to: see the --nobind option if you wish to do this. Using this option may help "solve" part of your problem by letting your upstream NAT attempt to keep whatever ephemeral port the client OS uses. This said, you should really look into what's causing your NAT to source 2 different streams onto the same tupple of IP/port combinations since that's clearly dysfunctional. When you used a different NAT unit, it modified the port, either because it does that for every outbound connection, or because it noticed an existing connection already using the same source port. -- Josh ------------------------------------------------------------------------------ See everything from the browser to the database with AppDynamics Get end-to-end visibility with application monitoring from AppDynamics Isolate bottlenecks and diagnose root cause in seconds. Start your free trial of AppDynamics Pro today! http://pubads.g.doubleclick.net/gampad/clk?id=48808831&iu=/4140/ostg.clktrk _______________________________________________ Openvpn-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/openvpn-users
