git.sur5r.net Git - bacula/docs/blob - docs/manuals/en/problems/firewalls.tex

   1 \chapter{Dealing with Firewalls}
   2 \label{FirewallsChapter}
   3 \index[general]{Dealing with Firewalls }
   4 \index[general]{Firewalls!Dealing with }
   5
   6 If you have a firewall or a DMZ installed on your computer, you may experience
   7 difficulties contacting one or more of the Clients to back them up. This is
   8 especially true if you are trying to backup a Client across the Internet.
   9
  10 \section{Technical Details}
  11 \index[general]{Technical Details }
  12 \index[general]{Details!Technical }
  13
  14 If you are attempting to do this, the sequence of network events in Bacula to
  15 do a backup are the following:
  16
  17 \begin{lstlisting}
  18 Console -> DIR:9101
  19 DIR     -> SD:9103
  20 DIR     -> FD:9102
  21 FD      -> SD:9103
  22 \end{lstlisting}
  23
  24
  25 Where hopefully it is obvious that DIR represents the Director, FD the File
  26 daemon or client, and SD the Storage daemon. The numbers that follow those
  27 names are the standard ports used by Bacula, and the \verb:->: represents the
  28 left side making a connection to the right side (i.e. the right side is the
  29 "server" or is listening on the specified port), and the left side is the
  30 "client" that initiates the conversation.
  31
  32 Note, port 9103 serves both the Director and the File daemon, each having its
  33 own independent connection.
  34
  35 If you are running {\bf iptables}, you might add something like:
  36
  37 \begin{lstlisting}
  38 -A FW-1-INPUT -m state --state NEW -m tcp -p tcp --dport 9101:9103 -j ACCEPT
  39 \end{lstlisting}
  40
  41 on your server, and
  42
  43 \begin{lstlisting}
  44 -A FW-1-INPUT -m state --state NEW -m tcp -p tcp --dport 9102 -j ACCEPT
  45 \end{lstlisting}
  46
  47 on your client. In both cases, I assume that the machine is allowed to
  48 initiate connections on any port. If not, you will need to allow outgoing
  49 connections on ports 9102 and 9103 on your server and 9103 on your client.
  50 Thanks to Raymond Norton for this tip.
  51
  52 \section{A Concrete Example}
  53 \index[general]{Example!Concrete }
  54 \index[general]{Concrete Example }
  55
  56 The following discussion was originally written by
  57 Jesse Guardiani because he has 'internal' and 'external' requiring the
  58 Director and the Client to use different IP addresses.  His original
  59 solution was to define two different Storage resources in the Director's
  60 conf file each pointing to the same Storage daemon but with different
  61 IP addresses.  In Bacula 1.38.x this no longer works, because Bacula makes
  62 a one-to-one association between a Storage daemon resource and a Device (such
  63 as an Autochanger).  As a consequence, I have modified his original
  64 text to a method that I believe will work, but is as of yet untested
  65 (KES - July 2006).
  66
  67 My bacula server is on the 192.168.1.0/24 network at IP address 192.168.1.52.
  68 For the sake of discussion we will refer to this network as the 'internal'
  69 network because it connects to the internet through a NAT'd firewall. We will
  70 call the network on the public (internet) side of the NAT'd firewall the
  71 'external' network. Also, for the sake of discussion we will call my bacula
  72 server:
  73
  74 \begin{lstlisting}
  75     server.int.mydomain.tld
  76 \end{lstlisting}
  77
  78 when a fully qualified domain name is required, or simply:
  79
  80 \begin{lstlisting}
  81     server
  82 \end{lstlisting}
  83
  84 if a hostname is adequate. We will call the various bacula daemons running on
  85 the server.int.mydomain.tld machine:
  86
  87 \begin{lstlisting}
  88     server-fd
  89     server-sd
  90     server-dir
  91 \end{lstlisting}
  92
  93 In addition, I have two clients that I want to back up with Bacula. The first
  94 client is on the internal network. Its fully qualified domain name is:
  95
  96 \begin{lstlisting}
  97     private1.int.mydomain.tld
  98 \end{lstlisting}
  99
 100 And its hostname is:
 101
 102 \begin{lstlisting}
 103     private1
 104 \end{lstlisting}
 105
 106 This machine is a client and therefore runs just one bacula daemon:
 107
 108 \begin{lstlisting}
 109     private1-fd
 110 \end{lstlisting}
 111
 112 The second client is on the external network. Its fully qualified domain name
 113 is:
 114
 115 \begin{lstlisting}
 116     public1.mydomain.tld
 117 \end{lstlisting}
 118
 119 And its hostname is:
 120
 121 \begin{lstlisting}
 122     public1
 123 \end{lstlisting}
 124
 125 This machine also runs just one bacula daemon:
 126
 127 \begin{lstlisting}
 128     public1-fd
 129 \end{lstlisting}
 130
 131 Finally, I have a NAT firewall/gateway with two network interfaces. The first
 132 interface is on the internal network and serves as a gateway to the internet
 133 for all the machines attached to the internal network (For example,
 134 server.int.mydomain.tld and private1.int.mydomain.tld). The second interface
 135 is on the external (internet) network. The external interface has been
 136 assigned the name:
 137
 138 \begin{lstlisting}
 139     firewall.mydomain.tld
 140 \end{lstlisting}
 141
 142 Remember:
 143
 144 \begin{lstlisting}
 145     *.int.mydomain.tld = internal network
 146         *.mydomain.tld = external network
 147 \end{lstlisting}
 148
 149 \subsection{The Bacula Configuration Files for the Above}
 150 \index[general]{Above!Bacula Configuration Files for the }
 151 \index[general]{Bacula Configuration Files for the Above }
 152
 153 server-sd manages a 4 tape AIT autoloader. All of my backups are written to
 154 server-sd. I have just *one* Device resource in my server-sd.conf file:
 155
 156 \begin{lstlisting}
 157 Autochanger {
 158   Name = "autochanger1";\
 159   Device = Drive0
 160   Changer Device = /dev/ch0;
 161   Changer Command = "/usr/local/sbin/chio-bacula %c %o %S %a";
 162 }
 163 Device {
 164   Name = Drive0
 165   DriveIndex = 0
 166   Media Type = AIT-1;
 167   Archive Device = /dev/nrsa1;
 168   Label Media = yes;
 169   AutoChanger = yes;
 170   AutomaticMount = yes;               # when device opened, read it
 171   AlwaysOpen = yes;
 172   Hardware End of Medium = No
 173   Fast Forward Space File = No
 174   BSF at EOM = yes
 175 }
 176 \end{lstlisting}
 177
 178 (note, please see
 179 \ilink{the Tape Testing}{FreeBSDTapes} chapter of this manual
 180 for important FreeBSD information.) However, unlike previously, there
 181 is only one Storage definition in my server-dir.conf file:
 182
 183 \begin{lstlisting}
 184 Storage {
 185   Name = "autochanger1"    # Storage device for backing up
 186   Address = Storage-server
 187   SDPort = 9103
 188   Password = "mysecretpassword"
 189   Device = "autochanger1"
 190   Media Type = AIT-1
 191   Autochanger = yes
 192 }
 193 \end{lstlisting}
 194
 195 Note that the Storage resource uses neither of the two addresses to
 196 the Storage daemon -- neither server.int.mydomain.tld nor
 197 firewall.mydomain.tld, but instead uses the address Storage-server.
 198
 199 What is key is that in the internal net, Storage-server is resolved
 200 to server.int.mydomain.tld, either with an entry in /etc/hosts, or by
 201 creating and appropriate DNS entry, and on the external net (the Client
 202 machine), Storage-server is resolved to firewall.mydomain.tld.
 203
 204
 205 In addition to the above, I have two Client resources defined in
 206 server-dir.conf:
 207
 208 \begin{lstlisting}
 209 Client {
 210   Name = private1-fd
 211   Address = private1.int.mydomain.tld
 212   FDPort = 9102
 213   Catalog = MyCatalog
 214   Password = "mysecretpassword"       # password for FileDaemon
 215 }
 216 Client {
 217   Name = public1-fd
 218   Address = public1.mydomain.tld
 219   FDPort = 9102
 220   Catalog = MyCatalog
 221   Password = "mysecretpassword"       # password for FileDaemon
 222 }
 223 \end{lstlisting}
 224
 225 And finally, to tie it all together, I have two Job resources defined in
 226 server-dir.conf:
 227
 228 \begin{lstlisting}
 229 Job {
 230   Name = "Private1-Backup"
 231   Type = Backup
 232   Client = private1-fd
 233   FileSet = "Private1"
 234   Schedule = "WeeklyCycle"
 235   Storage = "autochanger1-int"
 236   Messages = Standard
 237   Pool = "Weekly"
 238   Write Bootstrap = "/var/db/bacula/Private1-Backup.bsr"
 239   Priority = 12
 240 }
 241 Job {
 242   Name = "Public1-Backup"
 243   Type = Backup
 244   Client = public1-fd
 245   FileSet = "Public1"
 246   Schedule = "WeeklyCycle"
 247   Storage = "autochanger1-ext"
 248   Messages = Standard
 249   Pool = "Weekly"
 250   Write Bootstrap = "/var/db/bacula/Public1-Backup.bsr"
 251   Priority = 13
 252 }
 253 \end{lstlisting}
 254
 255 It is important to notice that because the 'Private1-Backup' Job is intended
 256 to back up a machine on the internal network so it resolves Storage-server
 257 to contact the Storage daemon via the internal net.
 258 On the other hand, the 'Public1-Backup' Job is intended to
 259 back up a machine on the external network, so it resolves Storage-server
 260 to contact the Storage daemon via the external net.
 261
 262 I have left the Pool, Catalog, Messages, FileSet, Schedule, and Director
 263 resources out of the above server-dir.conf examples because they are not
 264 pertinent to the discussion.
 265
 266 \subsection{How Does It Work?}
 267 \index[general]{How Does It Work? }
 268 \index[general]{Work!How Does It }
 269
 270 If I want to run a backup of private1.int.mydomain.tld and store that backup
 271 using server-sd then my understanding of the order of events is this:
 272
 273 \begin{enumerate}
 274 \item I execute my Bacula 'console' command on server.int.mydomain.tld.
 275 \item console connects to server-dir.
 276 \item I tell console to 'run' backup Job 'Private1-Backup'.
 277 \item console relays this command to server-dir.
 278 \item server-dir connects to private1-fd at private1.int.mydomain.tld:9102
 279 \item server-dir tells private1-fd to start sending the files defined in  the
 280    'Private1-Backup' Job's FileSet resource to the Storage resource
 281    'autochanger1', which we have defined in server-dir.conf as having the
 282 address:port of Storage-server, which is mapped by DNS to server.int.mydomain.tld.
 283 \item private1-fd connects to server.int.mydomain.tld:9103 and begins sending
 284    files.
 285    \end{enumerate}
 286
 287 Alternatively, if I want to run a backup of public1.mydomain.tld and store
 288 that backup using server-sd then my understanding of the order of events is
 289 this:
 290
 291 \begin{enumerate}
 292 \item I execute my Bacula 'console' command on server.int.mydomain.tld.
 293 \item console connects to server-dir.
 294 \item I tell console to 'run' backup Job 'Public1-Backup'.
 295 \item console relays this command to server-dir.
 296 \item server-dir connects, through the NAT'd firewall, to public1-fd at
 297    public1.mydomain.tld:9102
 298 \item server-dir tells public1-fd to start sending the files defined in  the
 299    'Public1-Backup' Job's FileSet resource to the Storage resource
 300    'autochanger1', which we have defined in server-dir.conf as having the
 301    same address:port as above of Storage-server, but which on this machine
 302    is resolved to firewall.mydomain.tld:9103.
 303 \item public1-fd connects to firewall.mydomain.tld:9103 and begins sending
 304    files.
 305    \end{enumerate}
 306
 307 \subsection{Important Note}
 308 \index[general]{Important Note }
 309 \index[general]{Note!Important }
 310
 311 In order for the above 'Public1-Backup' Job to succeed,
 312 firewall.mydomain.tld:9103 MUST be forwarded using the firewall's
 313 configuration software to server.int.mydomain.tld:9103. Some firewalls call
 314 this 'Server Publication'. Others may call it 'Port Forwarding'.
 315
 316 \subsection{Firewall Problems}
 317 \index[general]{Firewall Problems}
 318 \index[general]{Problems!Firewalls}
 319 Either a firewall or a router may decide to timeout and terminate
 320 open connections if they are not active for a short time. By Internet
 321 standards the period should be two hours, and should be indefinitely
 322 extended if KEEPALIVE is set as is the case by Bacula.  If your firewall
 323 or router does not respect these rules, you may find Bacula connections
 324 terminated. In that case, the first thing to try is turning on the
 325 {\bf Heart Beat Interval} both in the File daemon and the Storage daemon
 326 and set an interval of say five minutes.
 327
 328 Also, if you have denial of service rate limiting in your firewall, this
 329 too can cause Bacula disconnects since Bacula can at times use very high
 330 access rates. To avoid this, you should implement default accept
 331 rules for the Bacula ports involved before the rate limiting rules.
 332
 333 Finally, if you have a Windows machine, it will most likely by default
 334 disallow connections to the Bacula Windows File daemon.  See the
 335 Windows chapter of this manual for additional details.