Score:1

Connection reset by peer after firewall swap

cn flag

I have been working on a connection reset issue with SVN traffic after my client's firewall was replaced by a Sophos XG model early last year. Previously had Sonicwall. I opened multiple cases with Sophos support to try to isolate the issue and resolve but to no avail.

Current setup:

  • U.S. office is head office with SVN server running Fedora 15, Apache 2.2.22, and SVN 1.6.18.
  • There are 3 branch offices in 2 other countries and an IPSec VPN exists between head office and each branch office (star topology). NAT is not in use.
  • SVN clients are on Linux and Windows.
  • Communication for Windows file share, internal website, etc. do not have issues
  • When attempting to run a command such as "svn up" to update local system with repository, packet capture will show traffic passing between the SVN server and client) but after a few seconds the connection will be reset
  • Packet capture run on both systems shows a RST being sent from the other side. Meaning the server will show the client is sending the RST and the client will show the server is sending the RST.
  • Firewall rule for the VPN is set to allow all traffic between head office and branch offices, no filtering in place.
  • A developer can setup a SSH tunnel between his workstation in the branch office to the SVN server and sync data via the SSH tunnel, but using the direct communication between workstation and server over the VPN causes connection reset.
  • Firewall logs do not show traffic being dropped or denied.
  • One Sophos support rep thought issue may be related to the MSS number when reviewing packet captures but adjusting that on both firewalls did not make a difference.

I am at a loss at this point and looking to see if anyone can provide any pointers.

Edit: The issue is identified, Advanced Threat Protection in the firewall was causing the connections to reset even though we added the server and client IPs to the exception list. Even setting the policy to log from "log and drop" did not excuse the traffic from being blocked. Reached out to the vendor to review further. Logs do not show ATP blocking/disconnecting the traffic.

Martin avatar
kz flag
I have the predecessor of the sophos XG (sophos UTM) - my first advice would be to check all the logs of the XG, not just firewall - as there is Advanced threat protection, intrusion prevention, etc - my guess is, that one of those advanced firewall features is blocking you...
cn flag
I did check all of the different log sections and nothing comes up as being blocked. The Sophos support rep went into the CLI and we looked at a dropped packet command but they also gave us no results.
Martin avatar
kz flag
wow... ATP blocking traffic without producing logs, despite an existing policy - that is quite a bummer. This definitely sounds like a bug in the firmware of XG...
mangohost

Post an answer

Most people don’t grasp that asking a lot of questions unlocks learning and improves interpersonal bonding. In Alison’s studies, for example, though people could accurately recall how many questions had been asked in their conversations, they didn’t intuit the link between questions and liking. Across four studies, in which participants were engaged in conversations themselves or read transcripts of others’ conversations, people tended not to realize that question asking would influence—or had influenced—the level of amity between the conversationalists.