Question #4751
closedDistant VPN server can't receive his promises
Description
I have two networks linked by a VPN (OpenPVN) and the distant VPN server (in the "network A") can't receive his promises from the Rudder server (in the "net B"). All other clients, even in the distant network (A), work properly.
Network A : 192.168.92.0/24
Network B : 192.168.108.0/24
As I understand, the problem seems to be that when my distant VPN server was accepted on the Rudder server, it was registred with its "eth0" interface address IP. But now, when asking to receive his promises, it ask with its "tun0" interface address IP which is 10.8.0.1. So it is rejected by the Rudder server because of the UUID doesn't match with the IP previously registred. Here are the debug informations from cf-serverd :
rudder> -> Accepting a connection rudder> Obtained IP address of 10.8.0.1 on socket 7 from accept rudder> Accepting connection from "10.8.0.1" rudder> New connection...(from 10.8.0.1:sd 7) rudder> Spawning new thread... rudder> Allowing 10.8.0.1 to connect without (re)checking ID rudder> Non-verified Host ID is 10.8.0.1 (Using skipverify) rudder> Non-verified User ID seems to be root (Using skipverify) rudder> -> Public key identity of host "10.8.0.1" is "MD5=cb8201b1bca81bc884557edc12dcb9d3" rudder> A public key was already known from 10.8.0.1/10.8.0.1 - no trust required rudder> Adding IP 10.8.0.1 to SkipVerify - no need to check this if we have a key rudder> The public key identity was confirmed as root@10.8.0.1 rudder> -> Strong authentication of client 10.8.0.1/10.8.0.1 achieved rudder> -> Receiving session key from client (size=256)... rudder> Filename /var/rudder/share/dd3c2ec5-69cb-47ea-b2b4-bb8fb129e997/rules/cfengine-community/rudder_promises_generated is resolved to /var/rudder/share/dd3c2ec5-69cb-47ea-b2b4-bb8fb129e997/rules/cfengine-community/rudder_promises_generated rudder> Found a matching rule in access list (/var/rudder/share/dd3c2ec5-69cb-47ea-b2b4-bb8fb129e997/rules/cfengine-community/rudder_promises_generated in /var/rudder/share/dd3c2ec5-69cb-47ea-b2b4-bb8fb129e997) rudder> Host 10.8.0.1 denied access to /var/rudder/share/dd3c2ec5-69cb-47ea-b2b4-bb8fb129e997/rules/cfengine-community/rudder_promises_generated rudder> Access control in sync rudder> From (host=10.8.0.1,user=root,ip=10.8.0.1) rudder> REFUSAL of request from connecting host: (SYNCH 1397134555 STAT /var/rudder/share/dd3c2ec5-69cb-47ea-b2b4-bb8fb129e997/rules/cfengine-community/rudder_promises_generated) rudder> Terminating thread...
I added the tunnel network 10.8.0.0/30 in the authorized network in the administration panel, but still doesn't work. Routing is OK, everything ping correctly.
Updated by Vincent MEMBRÉ over 10 years ago
Hello Nicolas,
Thanks for opening your issue!
Does Rudder server resolve ip 10.8.0.1 as your node hostname? It uses file /etc/hosts to resolve ip and only authorize the node to access its directory if it can resolve.
by the way, which version of Rudder are you using ?
Updated by Nicolas KAROLAK over 10 years ago
Hello,
Actually it didn't resolve 10.8.0.1 as my node hostname, I added this line in `/etc/hosts` :
10.8.0.1 srv92-vpn01.adm.ltpsn.org srv92-vpn01
And after a reboot of the server it works ! Thanks.
I'm on the version 2.6.
Updated by Vincent MEMBRÉ over 10 years ago
- Tracker changed from Bug to Question
- Status changed from New to Resolved
- Target version set to 2.6.13
If you have other problems, you might look at this page for more advices: https://www.rudder-project.org/site/documentation/faq/some-reports-are-in-no-answer-for-a-node/
But don't hesitate to open an issue if you have a doubt :)
If this is a quite small install, I suggest you to try our latest version (2.10) to enjoy a faster Rudder with lots of new features :) http://www.rudder-project.org/rudder-doc-2.10/rudder-doc.html#_caution_cases