Guest User!

You are not Sophos Staff.

Thread Info
  • State Suggested Answer
  • Locked Locked
  • Replies 6 replies
  • Answers 2 answers
  • Subscribers 26 subscribers
  • Views 1840 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

Can't checkout SVN repository over VPN

Alan Spark

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.



This thread was automatically locked due to age.
  • 0

    Hello Alan,

    Thank you for contacting the Sophos Community.

    If you install Wireshark, are you able to see the same traffic for HTTP and HTTPS?

    Regards,

  • 0 in reply to emmosophos

    Hi Emmanuel,

    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.

    Thanks,

    Alan

  • 0 in reply to Alan Spark

    Hello Alan,

    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

    Regards,

  • 0 in reply to emmosophos

    Hi Emmanuel,

    Could you please provide a summary of this option and what enabling it will do? Is there no corresponding option in the dashboard?

    Thanks,

    Alan

  • 0 in reply to Alan Spark

    Hello Alan,

    Basically if for some reason the HTTP standard is not matching, we block it, by changing this to ON we allow the connection.

    Regards,

  • 0 in reply to emmosophos

    Hi Emmanuel,

    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.

    Thanks,

    Alan