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 83116 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.
Parents
  • 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 in reply to Joffer

    I am also struggling with this. I have set up a firewall rule for an FQDN group (including the host name used by another system at a friend's house) but I still can't connect.

    The web filter log does not show any denied requests. Maybe my problem isn't with XG at all even though it started after switching from UTM 9.

    Shouldn't the log be showing it if XG is blocking CrashPlan?

  • 0 in reply to Per-OlofLitby

    First verify that you have the correct network interface selected for Crashplan (in the app). I've had this change several times on my computer.. maybe because I've been playing around with VPN apps and stuff.. Right now it had shifted again and selected my tap interface, instead of eth6 which was my intel card with my local IP shown.

    Next you should be able to get this to work following my post (answer #3 in this thread) to get it to work. It still works for me, and the app is now v4.7.0

  • 0 in reply to Joffer

    Thanks.

    Unfortunately that wasn't the problem, I also have a number of interfaces and all of them were checked. I couldn't get the FQDN group policy to resolve the blocking of Crashplan. But after some experimenting I fixed it by creating a policy allowing unrestricted HTTPS access for the server where Crashplan runs.

    This method should be useful in other cases like this [:)]

  • 0 in reply to Per-OlofLitby

    ... I couldn't get the FQDN group policy to resolve the blocking of Crashplan. But after some experimenting I fixed it by creating a policy allowing unrestricted HTTPS access for the server where Crashplan runs...

     

    Seems I'm back with my old problems after upgrading XG to v16.0.x. I'm not able to connect to CrashPlan Central anymore (app v4.8.0).

    Do you have any advanced settings in that 'CP' rule of yours?

  • +1 in reply to Joffer

    There is a bug in v16.x which kills the access to Crashplan Central.

    Forumpost: https://community.sophos.com/products/xg-firewall/f/firewall-and-policies/81482/crashplan-connectivity-issues-with-xg-16/310556?pi2132219853=2&pi2132219849=84

    tl;dr; Workaround until fixed (maybe need to turn it back on, I don't know):

    Just log into console and run this

    console> system application_classification microapp-discovery off
Reply Children
No Data