We recently deployed the XG 135 and this morning I encountered an error when checking out an SVN repository when connected to VPN (same with both IPsec and SSL VPN).
The SVN repository in question has external repositories defined, so when you check it out it will in turn checkout other child repositories. The SVN checkout succeeds until it reaches these externals, which fail with the message "Error running context: An existing connection was forcibly closed by the remote host". I tried the same thing on a PC connected to the internal network and it checked out successfully.
Looking at the firewall log for my IP I can see corresponding "Could not associate packet to any connection" errors for each external checkout failure for src port 80 and destination port 65258.
We have VPN to LAN firewall rules defined for both IPsec and SSL VPN. I tried creating a rule in the opposite direction, LAN to VPN but this made no difference.
Finally I discovered that the external repositories are defined as HTTP URLs, and the problem happens if I checkout any repository over HTTP rather than HTTPS, not just repositories with SVN externals. When I change it to HTTPS I don't have any problems. I would like to understand what is causing this, and why it only happens over VPN.
Thank you for the feedback.
Can you try running this command from the Device Console of the XG (5>4)
console> set http relay_invalid_http_traffic on
Thank you for contacting the Sophos Community.
If you install Wireshark, are you able to see the same traffic for HTTP and HTTPS?
did you found a solution for it? I got the same problem when using VPN to lan
I tried Wireshark but I think it is difficult to compare HTTP and HTTPS traffic due to the nature of it. However, I did notice that it gets so far with the checkout and some of the folder structure comes across over HTTP and then we get a large number of RST packets.
I would appreciate any other advice.
No I have not found a solution yet, see my message above in response to the Wireshark request. Would be interested to know if you find a solution too.
Could you please provide a summary of this option and what enabling it will do? Is there no corresponding option in the dashboard?
Basically if for some reason the HTTP standard is not matching, we block it, by changing this to ON we allow the connection.
Thank you for the information. It sounds like this option is enabled for good reason by default so I'd rather not disable it if we can avoid it.
In case it helps anyone else, I have a workaround for the SVN externals problem. We were explicitly specifying the externals with the http:// protocol although we normally use https:// for the main checkout. It is possible to omit the protocol and simply start the externals with // and then SVN will use the same protocol as the overall checkout. This is good practice as it is generic in case protocols change in future.