Take the 2-minute tour ×
Server Fault is a question and answer site for system and network administrators. It's 100% free, no registration required.

We have a network 10.10.0.0/24, and one of the hosts (server0, 10.10.0.123) have puppetmaster installed. Others are connecting to it and everything seems fine.

Another one host (server1) is on another network and have openvpn connection to to puppetmaster host, openvpn network is 192.168.124.0/24 (192.168.124.1 - server0, 192.168.124.6 - server1).

Everything was working some time ago, but now when I'm trying to run puppet on server1 it fails with no message:

/usr/sbin/puppetd --no-daemonize --debug -o --server server0.fqdn
<...>
debug: Loaded state in 0.00 seconds
debug: Using cached certificate for ca
debug: Using cached certificate for server1
debug: Using cached certificate_revocation_list for ca
debug: catalog supports formats: b64_zlib_yaml marshal pson raw yaml; using pson
err: Could not retrieve catalog from remote server: 
info: Not using expired catalog for server1 from cache; expired at Fri May 27 15:56:15 +0300 2011
notice: Using cached catalog
err: Could not retrieve catalog; skipping run

Can't understand what am I missing. Telnet to puppet port works fine, as well as http. I've tried to connect to both 192.168.124.X and 10.10.0.X ips.

Here is the routing table to server1:

Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
192.168.124.1   192.168.124.5   255.255.255.255 UGH   0      0        0 tun0
192.168.124.5   0.0.0.0         255.255.255.255 UH    0      0        0 tun0
10.10.0.0       192.168.124.5   255.255.255.0   UG    0      0        0 tun0
192.168.10.0    0.0.0.0         255.255.255.0   U     0      0        0 eth0
0.0.0.0         192.168.10.X    0.0.0.0         UG    0      0        0 eth0

tcpdump of connection attempt:

15:44:17.556745 IP 192.168.124.6.59261 > 192.168.124.1.8140: S 3630206975:3630206975(0) win 5840 <mss 1460,sackOK,timestamp 333953908 0,nop,wscale 7>
15:44:17.938407 IP 192.168.124.1.8140 > 192.168.124.6.59261: S 3687729362:3687729362(0) ack 3630206976 win 5792 <mss 1366,sackOK,timestamp 3325304835 333953908,nop,wscale 7>
15:44:17.938417 IP 192.168.124.6.59261 > 192.168.124.1.8140: . ack 1 win 46 <nop,nop,timestamp 333954290 3325304835>
15:44:17.939187 IP 192.168.124.6.59261 > 192.168.124.1.8140: P 1:106(105) ack 1 win 46 <nop,nop,timestamp 333954291 3325304835>
15:44:18.274663 IP 192.168.124.1.8140 > 192.168.124.6.59261: F 1:1(0) ack 1 win 46 <nop,nop,timestamp 3325305329 333954290>
15:44:18.274893 IP 192.168.124.6.59261 > 192.168.124.1.8140: F 106:106(0) ack 2 win 46 <nop,nop,timestamp 333954626 3325305329>
15:44:18.533685 IP 192.168.124.1.8140 > 192.168.124.6.59261: R 3687729363:3687729363(0) win 0
15:44:18.753026 IP 192.168.124.1.8140 > 192.168.124.6.59261: R 3687729364:3687729364(0) win 0

Why does it resets connection?

There's nothing in puppetmaster log, even when running with -d switch.

Any ideas? Thanks.

share|improve this question
    
Run puppet master in --no-daemonize --debug mode and see what it says. –  Daniel C. Sobral May 30 '11 at 14:00
    
Nothing about this host :( –  rvs May 30 '11 at 14:12

1 Answer 1

Did you put the 192.168.124.0/24 network inside fileserver.conf? Also, are you sure date&time on client and server are reasonably synchronized?

Oh, I just noticed the server is natted! You said server0's IP is 10.10.0.123, but the connection is being made to 192.168.124.1 according to the dump. This might cause the server certificate to be rejected.

If I were you, I'd make sure to connect to the non-natted IP, and also make sure that the name of the puppet server matches its non-natted IP, and that the reverse of the IP matches the name.

Use a different name for the OpenVPN IP.

share|improve this answer
    
Yes, vpn network added to fileserver.conf. Date/time is synced, but servers are in different timezones (so local time have huge difference). I'll try to temporary switch servers to the same timezone (not on business hours, so I can't try this right now). –  rvs May 30 '11 at 14:14
1  
@rvs Different timezone shouldn't matter. Was the client certificate signed at all? And is there any NAT happening? –  Daniel C. Sobral May 30 '11 at 17:02
1  
@rvs I just noticed something else, and edited my answer. –  Daniel C. Sobral Jun 1 '11 at 14:27
1  
@rvs and does the name server0.fqdn solves to the IP 192.168.124.1 and vice versa on both client and server? –  Daniel C. Sobral Jun 1 '11 at 15:00
1  
@rvs But the other clients do access the 192.168.124.1 IP, do they? –  Daniel C. Sobral Jun 1 '11 at 18:23

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.