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.