Thread Info
  • State Verified Answer
  • Locked Locked
  • Replies 10 replies
  • Answers 1 answer
  • Subscribers 28 subscribers
  • Views 1736 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

FTP over non standard port failing

Josh Rogalski

We utilize a poorly written piece of software from the Federal government that sends and receives files over FTP using a non standard port (port 26581).  After we installed our new XG 550 the send and receive has stopped working entirely.  We got it to work 1 time and we still aren't sure why it worked.  This is a mission critical software for us and the Feds will not allow us to send it any other way besides this specifically written piece of software. We have an escalated ticket with Sophos and they are working as quickly as they can, but I wanted to see if anyone out in the world has experienced something similar with FTP?

 

The XG 550 is running version 18.0.1 where our last XG ran 17.5.14

 

We have tried firewall rules allowing all traffic to and from the box, and tried just about every trick we can think of to no avail. We can't go outside the firewall to bypass for a variety of reasons.  Appears that the XG is sending reset packets on the return traffic for some oddball reason.  Any assistance would be greatly appreciated.



This thread was automatically locked due to age.
Parents
  • +1

    After some discussion with a Sophos XG Engineer, what we discovered is that it was the SSL/TLS Inspection rules that is causing the issue.  As the software is a poorly written old as the hills Federal government written program, it doesn't adhere to many standards for FTP and other things.  The workaround for now is to go to:  "Rules and Policies > SSL/TLS inspection Rules" and toggle off the SSL/TLS Inspection, run the program upload/download, and then turn it back on. 

     

    Support will be helping me further to find a workaround rule that doesn't do the inspection to only that program, but for now that is the workaround.  Hope this helps others!

  • 0 in reply to Josh Rogalski

    Did you ever get a resolution?  I am configuring an XG125 and have the same problem with edconnect

  • 0 in reply to Daniel Olson

    My Guess is that is the ftpbounce-prevention that are the issue here. Login to the CLI go to meny 4 and change the ftpbounce-prevention to Data instead of control. That have worked for me when having issues with FTP traffic. 

    The command to change it.

    set advanced-firewall ftpbounce-prevention data

    to see the settings that are active use:

    show advanced-firewall

    And also please remember to allow the passive ports in the Firewall rule.

    //Rickard

  • 0 in reply to Daniel Olson

    edconnect is literally the exact same product we are having the problem with.  For now we are just toggling off that "SSL/TLS inspection" switch and having them transmit/recieve.  Then we turn it back on.  I have an escalated ticket with Sophos engineering but they suspect a special fix will be needed to take care of this.  Version 18 MR3 made no difference but we figured we would upgrade to it anyway and test.

    I'm not sure if I could add you to my escalated ticket that I have?  If you are interested I could try that to give more fuel to getting it done.  The engineer from Sophos (super knowledgeable person btw) mentioned it will probably be December before something that truly works is created.  Unfortunately it appears edconnect connects in a wildly insecure way (thanks feds).   

  • 0 in reply to RickardNordahl

    We apparently were changed over to "data" while Sophos engineering was taking a look at the issue.  I checked just now, but thank you for giving me this insight!

  • 0 in reply to Josh Rogalski

    Ok, can't you create a rule that don't inspect the traffic from your solution and let it flow thru? That should work until they come up with a solution to the problem.

Reply Children