4
\chapter{Dealing with Firewalls}
5
\label{FirewallsChapter}
6
\index[general]{Dealing with Firewalls }
7
\index[general]{Firewalls!Dealing with }
9
If you have a firewall or a DMZ installed on your computer, you may experience
10
difficulties contacting one or more of the Clients to back them up. This is
11
especially true if you are trying to backup a Client across the Internet.
13
\section{Technical Details}
14
\index[general]{Technical Details }
15
\index[general]{Details!Technical }
17
If you are attempting to do this, the sequence of network events in Bacula to
18
do a backup are the following:
29
Where hopefully it is obvious that DIR represents the Director, FD the File
30
daemon or client, and SD the Storage daemon. The numbers that follow those
31
names are the standard ports used by Bacula, and the \verb:->: represents the
32
left side making a connection to the right side (i.e. the right side is the
33
"server" or is listening on the specified port), and the left side is the
34
"client" that initiates the conversation.
36
Note, port 9103 serves both the Director and the File daemon, each having its
37
own independent connection.
39
If you are running {\bf iptables}, you might add something like:
43
-A FW-1-INPUT -m state --state NEW -m tcp -p tcp --dport 9101:9103 -j ACCEPT
51
-A FW-1-INPUT -m state --state NEW -m tcp -p tcp --dport 9102 -j ACCEPT
55
on your client. In both cases, I assume that the machine is allowed to
56
initiate connections on any port. If not, you will need to allow outgoing
57
connections on ports 9102 and 9103 on your server and 9103 on your client.
58
Thanks to Raymond Norton for this tip.
60
\section{A Concrete Example}
61
\index[general]{Example!Concrete }
62
\index[general]{Concrete Example }
64
The following discussion was originally written by
65
Jesse Guardiani because he has 'internal' and 'external' requiring the
66
Director and the Client to use different IP addresses. His original
67
solution was to define two different Storage resources in the Director's
68
conf file each pointing to the same Storage daemon but with different
69
IP addresses. In Bacula 1.38.x this no longer works, because Bacula makes
70
a one-to-one association between a Storage daemon resource and a Device (such
71
as an Autochanger). As a consequence, I have modified his original
72
text to a method that I believe will work, but is as of yet untested
75
My bacula server is on the 192.168.1.0/24 network at IP address 192.168.1.52.
76
For the sake of discussion we will refer to this network as the 'internal'
77
network because it connects to the internet through a NAT'd firewall. We will
78
call the network on the public (internet) side of the NAT'd firewall the
79
'external' network. Also, for the sake of discussion we will call my bacula
84
server.int.mydomain.tld
88
when a fully qualified domain name is required, or simply:
96
if a hostname is adequate. We will call the various bacula daemons running on
97
the server.int.mydomain.tld machine:
107
In addition, I have two clients that I want to back up with Bacula. The first
108
client is on the internal network. Its fully qualified domain name is:
112
private1.int.mydomain.tld
124
This machine is a client and therefore runs just one bacula daemon:
132
The second client is on the external network. Its fully qualified domain name
149
This machine also runs just one bacula daemon:
157
Finally, I have a NAT firewall/gateway with two network interfaces. The first
158
interface is on the internal network and serves as a gateway to the internet
159
for all the machines attached to the internal network (For example,
160
server.int.mydomain.tld and private1.int.mydomain.tld). The second interface
161
is on the external (internet) network. The external interface has been
166
firewall.mydomain.tld
174
*.int.mydomain.tld = internal network
175
*.mydomain.tld = external network
179
\subsection{The Bacula Configuration Files for the Above}
180
\index[general]{Above!Bacula Configuration Files for the }
181
\index[general]{Bacula Configuration Files for the Above }
183
server-sd manages a 4 tape AIT autoloader. All of my backups are written to
184
server-sd. I have just *one* Device resource in my server-sd.conf file:
189
Name = "autochanger1";\
191
Changer Device = /dev/ch0;
192
Changer Command = "/usr/local/sbin/chio-bacula %c %o %S %a";
198
Archive Device = /dev/nrsa1;
201
AutomaticMount = yes; # when device opened, read it
203
Hardware End of Medium = No
204
Fast Forward Space File = No
211
\ilink{the Tape Testing}{FreeBSDTapes} chapter of this manual
212
for important FreeBSD information.) However, unlike previously, there
213
is only one Storage definition in my server-dir.conf file:
218
Name = "autochanger1" # Storage device for backing up
219
Address = Storage-server
221
Password = "mysecretpassword"
222
Device = "autochanger1"
229
Note that the Storage resource uses neither of the two addresses to
230
the Storage daemon -- neither server.int.mydomain.tld nor
231
firewall.mydomain.tld, but instead uses the address Storage-server.
233
What is key is that in the internal net, Storage-server is resolved
234
to server.int.mydomain.tld, either with an entry in /etc/hosts, or by
235
creating and appropriate DNS entry, and on the external net (the Client
236
machine), Storage-server is resolved to firewall.mydomain.tld.
239
In addition to the above, I have two Client resources defined in
246
Address = private1.int.mydomain.tld
249
Password = "mysecretpassword" # password for FileDaemon
253
Address = public1.mydomain.tld
256
Password = "mysecretpassword" # password for FileDaemon
261
And finally, to tie it all together, I have two Job resources defined in
267
Name = "Private1-Backup"
271
Schedule = "WeeklyCycle"
272
Storage = "autochanger1-int"
275
Write Bootstrap = "/var/db/bacula/Private1-Backup.bsr"
279
Name = "Public1-Backup"
283
Schedule = "WeeklyCycle"
284
Storage = "autochanger1-ext"
287
Write Bootstrap = "/var/db/bacula/Public1-Backup.bsr"
293
It is important to notice that because the 'Private1-Backup' Job is intended
294
to back up a machine on the internal network so it resolves Storage-server
295
to contact the Storage daemon via the internal net.
296
On the other hand, the 'Public1-Backup' Job is intended to
297
back up a machine on the external network, so it resolves Storage-server
298
to contact the Storage daemon via the external net.
300
I have left the Pool, Catalog, Messages, FileSet, Schedule, and Director
301
resources out of the above server-dir.conf examples because they are not
302
pertinent to the discussion.
304
\subsection{How Does It Work?}
305
\index[general]{How Does It Work? }
306
\index[general]{Work!How Does It }
308
If I want to run a backup of private1.int.mydomain.tld and store that backup
309
using server-sd then my understanding of the order of events is this:
312
\item I execute my Bacula 'console' command on server.int.mydomain.tld.
313
\item console connects to server-dir.
314
\item I tell console to 'run' backup Job 'Private1-Backup'.
315
\item console relays this command to server-dir.
316
\item server-dir connects to private1-fd at private1.int.mydomain.tld:9102
317
\item server-dir tells private1-fd to start sending the files defined in the
318
'Private1-Backup' Job's FileSet resource to the Storage resource
319
'autochanger1', which we have defined in server-dir.conf as having the
320
address:port of Storage-server, which is mapped by DNS to server.int.mydomain.tld.
321
\item private1-fd connects to server.int.mydomain.tld:9103 and begins sending
325
Alternatively, if I want to run a backup of public1.mydomain.tld and store
326
that backup using server-sd then my understanding of the order of events is
330
\item I execute my Bacula 'console' command on server.int.mydomain.tld.
331
\item console connects to server-dir.
332
\item I tell console to 'run' backup Job 'Public1-Backup'.
333
\item console relays this command to server-dir.
334
\item server-dir connects, through the NAT'd firewall, to public1-fd at
335
public1.mydomain.tld:9102
336
\item server-dir tells public1-fd to start sending the files defined in the
337
'Public1-Backup' Job's FileSet resource to the Storage resource
338
'autochanger1', which we have defined in server-dir.conf as having the
339
same address:port as above of Storage-server, but which on this machine
340
is resolved to firewall.mydomain.tld:9103.
341
\item public1-fd connects to firewall.mydomain.tld:9103 and begins sending
345
\subsection{Important Note}
346
\index[general]{Important Note }
347
\index[general]{Note!Important }
349
In order for the above 'Public1-Backup' Job to succeed,
350
firewall.mydomain.tld:9103 MUST be forwarded using the firewall's
351
configuration software to server.int.mydomain.tld:9103. Some firewalls call
352
this 'Server Publication'. Others may call it 'Port Forwarding'.
354
\subsection{Firewall Problems}
355
\index[general]{Firewall Problems}
356
\index[general]{Problems!Firewalls}
357
Either a firewall or a router may decide to timeout and terminate
358
open connections if they are not active for a short time. By Internet
359
standards the period should be two hours, and should be indefinitely
360
extended if KEEPALIVE is set as is the case by Bacula. If your firewall
361
or router does not respect these rules, you may find Bacula connections
362
terminated. In that case, the first thing to try is turning on the
363
{\bf Heart Beat Interval} both in the File daemon and the Storage daemon
364
and set an interval of say five minutes.
366
Also, if you have denial of service rate limiting in your firewall, this
367
too can cause Bacula disconnects since Bacula can at times use very high
368
access rates. To avoid this, you should implement default accept
369
rules for the Bacula ports involved before the rate limiting rules.
371
Finally, if you have a Windows machine, it will most likely by default
372
disallow connections to the Bacula Windows File daemon. See the
373
Windows chapter of this manual for additional details.
added
removed
manuals/de/problems/firewalls.tex
