Tuc at T-B-O-H.NET wrote:
> I tried to start a 2nd OpenVPN instance on my server, and a 2nd
> OpenVPN instance on my client. They are both FreeBSD 5. I copied my entire
> directory over from "openvpn" to "openvpn2". On the client, I changed the
> IP I wanted the client to contact the server on. (I needed to do this since
> the remote site would route the traffic to that IP out a different transit
> provider). On both of them I changed the IP set (10.2.0.X to 10.3.0.X) and
> the ports (From 5001 to 5002). I started them up, but they don't seem to
> sync. If I change the IP the client tries to contact the server on back
> to the base one, works perfectly.
> Is there something about the certificate and the forward/reverse
> When it ISNT working, I get :
> Sun Aug 5 23:30:36 2007 24: TLS: tls_pre_decrypt: new session incoming connection from 188.8.131.52:10169
> on the server, and
> Sun Aug 5 23:30:36 2007 Re-using SSL/TLS context
> Sun Aug 5 23:30:36 2007 LZO compression initialized
> Sun Aug 5 23:30:36 2007 Control Channel MTU parms [ L:1300 D:138 EF:38 EB:0 ET:0 EL:0 ]
> Sun Aug 5 23:30:36 2007 Preserving previous TUN/TAP instance: tun1
> Sun Aug 5 23:30:36 2007 Data Channel MTU parms [ L:1300 D:1300 EF:42 EB:135 ET:0 EL:0 AF:3/1 ]
> Sun Aug 5 23:30:36 2007 Local Options hash (VER=V4): '8c473bbe'
> Sun Aug 5 23:30:36 2007 Expected Remote Options hash (VER=V4): '4e312712'
> Sun Aug 5 23:30:36 2007 UDPv4 link local (bound): [undef]:5002
> Sun Aug 5 23:30:36 2007 UDPv4 link remote: A.B.C.D:5002
> on the client
> I don't have a local directive. I thought that it
> would bind to "*" and the fact that I changed the ports would keep them
> away from each other.
As long as each server runs on a unique port they can listen on the
global address to accept connections from anywhere, so this is fine.
When you copy the directory, have you updated any paths inside the
config file of the new setup? Other than a shared file between the two
(such as the ifconfig-pool-persist option) the 2 instances should be
completely separate. Also verify that each instance is using a separate
adapter on the server and client (if the client is dynamically bringing
up the tun adapter it should handle this automatically.) If both those
ideas don't help, you could try to turn off the persistent-tun setting;
I'm noticing that the client is re-using the previous tun instance.
While I don't suspect this is a problem, it's one more thing you can try.
Description: OpenPGP digital signature