Guest User!

You are not Sophos Staff.

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

Crashplan Connectivity Issues with XG 16

Since upgrading today to XG 16 (not beta) Crashplan hasn't been working.

It doesn't seem to connect.

I've checked the rules and the IP has no extra features turned on (Malware/Webpolicy) it's statically bypassed

I tried turning off IPS and no luck, also the firewall shows the traffic green (allowed) out?

 

So with this version Logging is improved which is great! So found out that It's an invalid traffic issue?

2016-10-11 11:02:55
Invalid Traffic
Denied
-
0
PortB
-
162.222.42.64 :TCP(443)

01001

Anyone could help me here with that? thank you!

Regards



This thread was automatically locked due to age.
Parents
  • Hi,

    The traffic is denied as invalid which means there is no firewall rule to forward the traffic. Create a plain firewall rule at the TOP and check the connectivity.

    Fw Rule: Lan > any > Wan | webfilter : None, Application filter: None

    Thanks

Reply
  • Hi,

    The traffic is denied as invalid which means there is no firewall rule to forward the traffic. Create a plain firewall rule at the TOP and check the connectivity.

    Fw Rule: Lan > any > Wan | webfilter : None, Application filter: None

    Thanks

Children
  • Hi Sachin,

     

    I have those rules already, according to the firewall.


    Investigating it a little more last night to find the outbound traffic is flowing though fine, it seems to not allow it back in.

     

    I tried an any rule inbound from crashplan too:

      

     

    And the rule that allows static IP's out with nothing below the rule except NAT policy:

     

    The FW rule here in logs shows allowed out, but I don't see the traffic back or If I do manage to get it to show (playing around) it'll show denied

     

    Thanks for your help

  • Hi, 

    XG does not require a WAN_LAN rule as it is a stateful-inspection firewall. 

    I would again recommend you to create a FW-rule on TOP like:

    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 = ANY

    Action = Accept

    Routing = Default (Masq)

    Malware Scanning = Default (off)

    Policy for User Applications

    • Application Control = None
    • Web Filter = None 
    • Intrusion Prevention = None
    • Traffic Shaping Policy = None

    Log Traffic (optional)

    Security Heartbeat = Off

    Thanks

  • Yep, It was just testing to prove.

     

    So added top rule for everything to go out like this:

     

     

     

    and got the same result as before:

    (NAT)

     

    Note this wasn't an issue with 15 and utm :)

    Thank you for your help!

  • Hi,

    Go to system> diagonostics> services> web proxy restart. Try to connect through CrashPlan servers and post the drop packet capture logs through CLI, refer #1.1 in the guide

    How about doing this in a different way? Check in what network range does the CrashPlan URLs resides and add the complete network subnet in the Destination zone instead of adding the FQDNs in the FW rule. Suppose 216.17.x.x /21. Any help with that?

    Also, verify the steps given in the KB articles here:

    https://support.code42.com/CrashPlan/4/Troubleshooting/Connecting_To_CrashPlan_Central_Or_CrashPlan_PRO_Online

    https://support.code42.com/CrashPlan/4/Troubleshooting/Connecting_To_Code42_Cloud_Destinations_From_A_Proxy_Server

    Thanks

  • Here are some drop packet logs.

    ___central.crashplan.com___


    2016-10-12 08:08:00 0102021 IP 192.168.1.110.42022 > 216.17.8.48.4287 : proto TCP: P 2010382188:2010382241(53) win 276 checksum : 9615
    0x0000:  4500 005d 234f 4000 4006 74f4 c0a8 016e  E..]#O@.@.t....n
    0x0010:  d811 0830 a426 10bf 77d3 ff6c d89d de13  ...0.&..w..l....
    0x0020:  5018 0114 258f 0000 1703 0300 30e0 d8b8  P...%.......0...
    0x0030:  a4b6 717d 0ffc 516e 0aed 199e 9194 c392  ..q}..Qn........
    0x0040:  3cc1 fa90 f5d6 dc74 46f4 89e5 84fe 42a5  <......tF.....B.
    0x0050:  f81d de8c 1b1e 40cc 86a3 bf82 d4         ......@......
    Date=2016-10-12 Time=08:08:00 log_id=0102021 log_type=Firewall log_component=Invalid_Traffic log_subtype=Denied log_status=N/A log_priority=Alert duration=N/A in_dev=Port1 out_dev= inzone_id=0 outzone_id=0 source_mac=00:08:9b:xx:xx:xx dest_mac=e4:8d:8c:xx:xx:xx l3_protocol=IP source_ip=192.168.1.110 dest_ip=216.17.8.48 l4_protocol=TCP source_port=42022 dest_port=4287 fw_rule_id=0 policytype=0 live_userid=0 userid=0 user_gp=0 ips_id=0 sslvpn_id=0 web_filter_id=0 hotspot_id=0 hotspotuser_id=0 hb_src=0 hb_dst=0 dnat_done=0 icap_id=0 app_filter_id=0 app_category_id=0 app_id=0 category_id=0 bandwidth_id=0 up_classid=0 dn_classid=0 source_nat_id=0 cluster_node=0 inmark=0x0 nfqueue=0 scanflags=0 gateway_offset=0 max_session_bytes=0 drop_fix=0 ctflags=0 connid=0 masterid=0 status=0 state=0 sent_pkts=N/A recv_pkts=N/A sent_bytes=N/A recv_bytes=N/A tran_src_ip=N/A tran_src_port=N/A tran_dst_ip=N/A tran_dst_port=N/A



    ___duf-sea.crashplan.com___


    2016-10-12 08:10:27 0102021 IP 192.168.1.52.39983 > 162.222.42.222.443 : proto TCP: P 4167247613:4167247645(32) win 237 checksum : 30575
    0x0000:  4500 0054 f463 4000 4006 b6a7 c0a8 0134  E..T.c@.@......4
    0x0010:  a2de 2ade 9c2f 01bb f863 26fd eb4d f08c  ..*../...c&..M..
    0x0020:  8018 00ed 776f 0000 0101 080a 0151 5880  ....wo.......QX.
    0x0030:  2697 02aa 8ace e7ec 4539 acee f285 2d8c  &.......E9....-.
    0x0040:  0a83 d3a2 e0af 5825 e85f c783 5e51 67ea  ......X%._..^Qg.
    0x0050:  9e14 a242                                ...B
    Date=2016-10-12 Time=08:10:27 log_id=0102021 log_type=Firewall log_component=Invalid_Traffic log_subtype=Denied log_status=N/A log_priority=Alert duration=N/A in_dev=Port1 out_dev= inzone_id=0 outzone_id=0 source_mac=00:0c:29:xx:xx:xx dest_mac=e4:8d:8c:xx:xx:xx l3_protocol=IP source_ip=192.168.1.52 dest_ip=162.222.42.222 l4_protocol=TCP source_port=39983 dest_port=443 fw_rule_id=0 policytype=0 live_userid=0 userid=0 user_gp=0 ips_id=0 sslvpn_id=0 web_filter_id=0 hotspot_id=0 hotspotuser_id=0 hb_src=0 hb_dst=0 dnat_done=0 icap_id=0 app_filter_id=0 app_category_id=0 app_id=0 category_id=0 bandwidth_id=0 up_classid=0 dn_classid=0 source_nat_id=0 cluster_node=0 inmark=0x0 nfqueue=0 scanflags=0 gateway_offset=0 max_session_bytes=0 drop_fix=0 ctflags=0 connid=0 masterid=0 status=0 state=0 sent_pkts=N/A recv_pkts=N/A sent_bytes=N/A recv_bytes=N/A tran_src_ip=N/A tran_src_port=N/A tran_dst_ip=N/A tran_dst_port=N/A

    ----

    For reference, here is the discussion in the beta forum: https://community.sophos.com/products/xg-firewall/v16beta/f/sfos-v16-beta-issues-bugs/79608/crashplan---unable-to-connect#pi2132219853=1

    This all worked fine in v15. 

  • Thanks for point that out David,

     

    I didn't see that post (was not a member of the BETA group)

     

    That's exactly the issue I'm facing here. Glad I'm no the only one

     

    Regards

  • Hi David,

    Looking at the logs again, 

    Date=2016-10-12 Time=08:08:00 log_id=0102021 log_type=Firewall log_component=Invalid_Traffic log_subtype=Denied log_status=N/A log_priority=Alert duration=N/A in_dev=Port1 out_dev= inzone_id=0 outzone_id=0 source_mac=00:08:9b:xx:xx:xx dest_mac=e4:8d:8c:xx:xx:xx l3_protocol=IP source_ip=192.168.1.110 dest_ip=216.17.8.48 l4_protocol=TCP source_port=42022 dest_port=4287 fw_rule_id=0 policytype=0 live_userid=0 userid=0 user_gp=0 ips_id=0 sslvpn_id=0 web_filter_id=0 hotspot_id=0 hotspotuser_id=0 hb_src=0 hb_dst=0 dnat_done=0 icap_id=0 app_filter_id=0 app_category_id=0 app_id=0 category_id=0 bandwidth_id=0 up_classid=0 dn_classid=0 source_nat_id=0 cluster_node=0 inmark=0x0 nfqueue=0 scanflags=0 gateway_offset=0 max_session_bytes=0 drop_fix=0 ctflags=0 connid=0 masterid=0 status=0 state=0 sent_pkts=N/A recv_pkts=N/A sent_bytes=N/A recv_bytes=N/A tran_src_ip=N/A tran_src_port=N/A tran_dst_ip=N/A tran_dst_port=N/A

    The traffic is dropped as an invalid traffic as no firewall rule is found to forward the connection. Can you also try to flush the v4 connection table, take SSH to XG and execute,

    system diagnostics utilities connections v4 delete src_ip x.x.x.x (execute it several times on src and dest bothways). Also, I read some articles for crashplan and referred them in my previous post can you verify the information?

    Thanks

  • The traffic is dropped as an invalid traffic as no firewall rule is found to forward the connection. Can you also try to flush the v4 connection table, take SSH to XG and execute,

    system diagnostics utilities connections v4 delete src_ip x.x.x.x (execute it several times on src and dest bothways). Also, I read some articles for crashplan and referred them in my previous post can you verify the information?

    No rule?  It's right here and worked perfectly in v15.  Other users have reported the same thing.

    The drop log was taken immediately after booting from v15 to v16.

    The one CP reference is for an explicit proxy, so that doesn't apply to my configuration.

  • It's exactly the same as David all that's different is the ip it's going to as i'm connected to another crash plan server- 

     

    2016-10-12 17:47:21 0102021 IP 162.222.42.207.443 > 10.10.7.1.41464 : proto TCP: R 3399830217:3399830217(0) checksum : 6150

    0x0000:  4500 0028 c2bd 4000 3506 a45a a2de 2acf  E..(..@.5..Z..*.

    0x0010:  0a0a 0701 01bb a1f8 caa5 4ac9 0000 0000  ..........J.....

    0x0020:  5004 0000 1806 0000                      P.......

    Date=2016-10-12 Time=17:47:21 log_id=0102021 log_type=Firewall log_component=Invalid_Traffic log_subtype=Denied log_status=N/A log_priority=Alert duration=N/A in_dev=PortB out_dev= inzone_id=0 outzone_id=0 source_mac=7c:4c:a5:8b:8e:98 dest_mac=00:50:56:a5:3c:0f l3_protocol=IP source_ip=162.222.42.207 dest_ip=10.10.7.1 l4_protocol=TCP source_port=443 dest_port=41464 fw_rule_id=0 policytype=0 live_userid=0 userid=0 user_gp=0 ips_id=0 sslvpn_id=0 web_filter_id=0 hotspot_id=0 hotspotuser_id=0 hb_src=0 hb_dst=0 dnat_done=0 icap_id=0 app_filter_id=0 app_category_id=0 app_id=0 category_id=0 bandwidth_id=0 up_classid=0 dn_classid=0 source_nat_id=0 cluster_node=0 inmark=0x0 nfqueue=0 scanflags=0 gateway_offset=0 max_session_bytes=0 drop_fix=0 ctflags=0 connid=0 masterid=0 status=0 state=0 sent_pkts=N/A recv_pkts=N/A sent_bytes=N/A recv_bytes=N/A tran_src_ip=N/A tran_src_port=N/A tran_dst_ip=N/A tran_dst_port=N/A

     

    2016-10-12 17:47:21 0102021 IP 162.222.42.207.443 > 10.10.7.1.41464 : proto TCP: R 3399830217:3399830217(0) checksum : 6150

    0x0000:  4500 0028 c2be 4000 3506 a459 a2de 2acf  E..(..@.5..Y..*.

    0x0010:  0a0a 0701 01bb a1f8 caa5 4ac9 0000 0000  ..........J.....

    0x0020:  5004 0000 1806 0000                      P.......

    Date=2016-10-12 Time=17:47:21 log_id=0102021 log_type=Firewall log_component=Invalid_Traffic log_subtype=Denied log_status=N/A log_priority=Alert duration=N/A in_dev=PortB out_dev= inzone_id=0 outzone_id=0 source_mac=7c:4c:a5:8b:8e:98 dest_mac=00:50:56:a5:3c:0f l3_protocol=IP source_ip=162.222.42.207 dest_ip=10.10.7.1 l4_protocol=TCP source_port=443 dest_port=41464 fw_rule_id=0 policytype=0 live_userid=0 userid=0 user_gp=0 ips_id=0 sslvpn_id=0 web_filter_id=0 hotspot_id=0 hotspotuser_id=0 hb_src=0 hb_dst=0 dnat_done=0 icap_id=0 app_filter_id=0 app_category_id=0 app_id=0 category_id=0 bandwidth_id=0 up_classid=0 dn_classid=0 source_nat_id=0 cluster_node=0 inmark=0x0 nfqueue=0 scanflags=0 gateway_offset=0 max_session_bytes=0 drop_fix=0 ctflags=0 connid=0 masterid=0 status=0 state=0 sent_pkts=N/A recv_pkts=N/A sent_bytes=N/A recv_bytes=N/A tran_src_ip=N/A tran_src_port=N/A tran_dst_ip=N/A tran_dst_port=N/A

  • And just to demonstrate connectivity per the CrashPlan KB:

    ---------------

    $ telnet central.crashplan.com  443
    Trying 216.17.8.8...
    Connected to central.crashplan.com.
    Escape character is '^]'.



    ?cA-18782|com.code42.messaging.security.SecurityProviderReadyMessage¶¢"=s:́£
                                                                                 ?!ùª?nDZ?Y0àã¿XÂÔLH?

    ---------------

    But the actual application data stream gets smacked by v16 to Invalid Traffic.

    With 100% identical firewall rules, I revert back to v15 and everything works.