I believe your problem is caused by an internal storage daemon and an
external client. When the bacula director starts a job, the director tells
the file daemon to backup X files to X storage daemon with X ip and X
authentication. Your file daemon is attempting to connect to your storage
daemon with it's internal ip.
Sincerely,
-Michael
On 10/17/07, Mateus Interciso <[EMAIL PROTECTED]> wrote:
>
> Hello, I have this set up(simplified)
> [External server]---->Firewall/Nat----->Internet-->Firewall/NAT-->Bacula
> Let's say the external server I want to back up has a public ip of
> 222.222.222.222, and the Firewall/NAT that lies on the internal network
> of Bacula has the ip 200.200.200.200, and bacula has the internal ip
> 10.100.0.4, by bacula I mean the director, storage daemon, and a file
> daemon as well.
> Now, I've configured this storage on the bacula-dir.conf of the Bacula
> server:
> Storage {
> Name = PublicTest
> Address = 200.200.200.200
> SDPort = 9103
> Password = "rHdomafNas1GeiHAYqsHAr1axgMthcKtTh3elwpDEBRw"
> Device = Weekly
> Media Type = File
> }
>
> As well as this one:
>
> Storage {
> Name = FileWeekly
> Address = 10.100.0.4
> SDPort = 9103
> Password = "rHdomafNas1GeiHAYqsHAr1axgMthcKtTh3elwpDEBRw"
> Device = Weekly
> Media Type = File
> }
>
> Now, since I can go into the bacula console, and connect to the client,
> show it's status, and make an estimate of the backup I'll make normally,
> I think that the job and pool are configured correctly, as well as (at
> least part of) the firewall.
> If I run, the backup job, with the PublicTest, or FileWeekly storage, I
> allways get this connection timeout error:
>
> 17-Oct 15:53 behemot-dir JobId 153: Warning: bsock.c:123 Could not
> connect to Storage daemon on 200.200.200.200:9103. ERR=Connection timed
> out
>
> Since other jobs do run normally(when they are in the internal network)
> I'm getting a little confused here. Tcpdump shows this, when I try to use
> the PublicTest storage:
>
> [External Server]
> 14:56:35.956696 IP 10.0.10.4.9102 > 200.200.200.200.45190: . ack 677 win
> 1984 <nop,nop,timestamp 1116655584 107627403>
>
> [Firewall]
> 15:27:24.892811 IP 10.100.0.4.60741 > 222.222.222.222.9103: S
> 3206713682:3206713682(0) win 5840 <mss 1460,sackOK,timestamp 107913615
> 0,nop,wscale 7>
> (keeps repeating the same request, there's no ack returning)
>
> 10.0.10.4 is the internal IP of the External Server.
> The strange thing, is that it shows just this, for all the connections
> using PublicTest storage, but if I use the FileWeekly, it shows all the
> connections, sending requests, connecting, getting the answers back, etc,
> but when it tryes to connect to the storage...
>
> [External Server]
> 14:54:11.742070 IP 10.0.10.4.45228 > 10.100.0.4.9103: S
> 1535168577:1535168577(0) win 5840 <mss 1460,sackOK,timestamp 1116511348
> 0,nop,wscale 2>
>
> Which of course would never work, since it's trying to connect to an
> internal ip that does not exist...
> I'm getting crazy over this, can someone please help me?
>
> Thanks a lot
>
> Mateus
>
>
> -------------------------------------------------------------------------
> This SF.net email is sponsored by: Splunk Inc.
> Still grepping through log files to find problems? Stop.
> Now Search log events and configuration files using AJAX and a browser.
> Download your FREE copy of Splunk now >> http://get.splunk.com/
> _______________________________________________
> Bacula-users mailing list
> Bacula-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bacula-users
>
-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems? Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/
_______________________________________________
Bacula-users mailing list
Bacula-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bacula-users
