Guest User!

You are not Sophos Staff.

Thread Info
  • State Verified Answer
  • +1 person also asked this people also asked this
  • Locked Locked
  • Replies 18 replies
  • Answers 4 answers
  • Subscribers 33 subscribers
  • Views 83113 views
  • Users 0 members are here
Options
Suggested
This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

Anyone successfully running Crashplan backups through an XG?

PeterNikolaidis

Greetings!


I recently replaced a UTM 120 with an XG 125. Crashplan Pro (usually running on ports 443 and 4242) hasn't worked since. Taking the XG out of the loop allows communication, so it's definitely something with the new unit's config, but even if I allow all traffic out and disable HTTP/HTTPS scanning, it won't communicate. Any suggestions?

Thanks,

Peter



This thread was automatically locked due to age.
  • 0
    You have to creates fqdn host's for the url's CrashPlan in using. You can get the URL from the application by clicking on crashplan central. This does require a little bit of manual management. I create the individual hosts, then add then to a CrashPlan FGDN group. Then apply a LANtoWan policy allowing the group as a destination network and the client will connect.
  • 0

    I've got the same problem with Crashplan for Home. It won't connect, or log in if I reinstall the app.

    EricWalsh - care to share your list of fqdn hosts? And how did you create the policy?

    Why do we need that? I'm allowing ALL traffic outbound (home use)

    Internet Outbound rule:

    Crashplan test policy (doesn't seem to work if I disable my internet access policy - can't telnet to central.crashplan.com)

  • 0 in reply to Joffer

    Ok so I finally got this working on my side, for Crashplan for Home (v4.5.2).

    I made a case with Crashplan Support, reffering to this thread as well. This is what I got back:

    The only FQDN I think you should need is your server address:

    arb-msp.crashplan.com:4285

    This is definitely an odd issue, and certainly seems like something to talk to Sophos about. Your firewall shouldn't be blocking things you tell it not to block.

    I had already created a FQDN Group with all crashplan FQDNs I could find in the logs:

    • arb-msp.crashplan.com
    • central.crashplan.com
    • reflector.crashplan.com
    • www.crashplan.com

    I then created a new 'User/Network Rule' like this:

    Rule Name = CrashPlan

    Identity

    • Match rule based on user Identity = Off

    Source

    • Zone = LAN
    • Networks = Any
    • Service = Any
    • Schedule = All The Time

    Destination

    • Zone = WAN
    • Networks = FQDNgroup-CrashPlan

    Action = Accept

    Routing = Default (Masq)

    Malware Scanning = Default (off)

    Policy for User Applications

    • Application Control = None
    • Web Filter = None  <-- THIS NEEDS TO BE TOTALLY DISABLED. "Allow All" doesn't work.
    • Intrusion Prevention = None
    • Traffic Shaping Policy = None

    Log Traffic (optional)

    Security Heartbeat = Off

    The most important setting here was that I couldn't connect with Web Filter set to anything but 'None'. Even 'Allow All' didn't work. So it seems to be a bug or problem with the Web Filter. It works with Application Control set to 'Allow All'.

    I have not investigated other settings, nor removed FQDNs from my FQDN group. Shaping, special ports (only 443 or 4285?) etc could be tested, but nothing I would bother with for my home network. I'm finally getting my computer backed up again after two weeks being blocked.

  • 0
    My FQDN Group consists of:
    central.crashplan.com
    adf-sea.crashplan.com
    cyb-sea.crashplan.com
    epe-sea.crashplan.com

    I run both Windows and OS X clients that backup to CrashPlan Online as well as host my own storage. I just keep in eye out on the app to make sure it connects. If it doesn't, I look up where it's trying to connect under the CrashPlan Central destination tab. If something new appears, then I just add to the FQDN group. I don't really think this is something broken as I use Cyberoam UTM and it's the exact same way. XG Firewall after seems to be a rebranded and redesigned Cyberoam UTM. There really are very few differences between them.
  • 0 in reply to EricWalsh
    Well somethings off when you can't run it true web filter with 'allow all' options.. But it was fixed anyway with putting it to 'none'..
  • 0

    This would be the same issue as on the Cyberoams I would guess. You need to make sure you don't have "Deny Unknown Protocol" enabled in the HTTP/HTTPS Configurations of the Web Content Filter.

    EDIT: Just tested and this has no effect, as stated above you need to create a firewall policy that uniquely identifies the CrashPlan traffic and then specifically has the web filter policy set to None. Allow All doesn't work, it has to be set to None.

  • 0

    Well I can't get this to work - yet.  I am running the latest patch for XG, and it's possible the url's are not correct, however I don't think I can get them unless I log in, and I can't log in.  Can anyone be more specific about where to find the crashplan URL's?

  • 0 in reply to QuentinJackson

    Scratch that, suddenly I'm able to log in, but getting the dreaded 'waiting for connection'.

  • 0 in reply to QuentinJackson

    They're not posted anywhere by CrashPlan. The few I listed previously I've gotten from the CrashPlan desktop app. On the main screen, if you click on CrashPlan Central, it shows you the details of the connection including the url it's trying to use. I just watch for my app not to connect and add a new url to the FQDN Group I created if needed. But using that list it's been quite some time since I've had an issue. But the assignment of url's could be regional and you could get something different possibly.

  • 0 in reply to EricWalsh

    Ah, that was the two clues I needed.  For the record the two things that were throwing me:  I have no CrashPlan Central - I'ts called CrashPlan Australia on mine and from there realising that I needed to click on that I was able to find a new FQDN, which for the record is: ada-syd.crashplan.com


    It is now working.

    What a rigmarole!

    Thanks!