Guest User!

You are not Sophos Staff.

Thread Info
  • State Verified Answer
  • Locked Locked
  • Replies 12 replies
  • Subscribers 27 subscribers
  • Views 23860 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

PHP Timeout

StefanoColombo

We have the following issue .

Accessing an external web server for an application in PHP which has to create a PDF, from a selection made by the user ,and then provide the link to it , it fails by timing out

If we disable the proxy and the user goes through the firewall it then is successful

the PHP process takes 1 minute to generate the PDF and provide the link

If we make a smaller selection the process takes less and it goes through even with the proxy

 

Is there a way to increase such timeout ?

 

thanks



This thread was automatically locked due to age.
Parents
  • 0

    Stefano,

    are you using WAF rule to publish PHP webserver?

    Did you find something useful in the logs?

    Thanks

  • 0 in reply to lferrara

    The Server is published externally by the application provider .

    The logs provided no help since the last line logged is the ...php page which is accepted .

  • 0 in reply to StefanoColombo

    Stefano,

    check the advanced-parameters from console using the command "show show advanced-firewall" and try to increate the tcp-est-idle-timeout using the command:

    set advanced-firewall tcp-est-idle-timeout "value in seconds"

    Regards

  • 0 in reply to lferrara

    Here is the current values

            Strict Policy                           : on
            FtpBounce Prevention                    : control
            Tcp Conn. Establishment Idle Timeout    : 10800
            UDP Timeout Stream                      : 60
            Fragmented Traffic Policy               : allow
            Midstream Connection Pickup             : off
            TCP Seq Checking                        : on
            TCP Window Scaling                      : on
            TCP Appropriate Byte Count              : on
            TCP Selective Acknowledgements          : on
            TCP Forward RTO-Recovery[F-RTO]         : off
            TCP TIMESTAMPS                          : off
            Strict ICMP Tracking                    : off
            ICMP Error Message                      : allow
            IPv6 Unknown Extension Header           : deny

     

    the settings of UDP Streams is the only that looks close to the timeout we're experiencing

  • 0 in reply to StefanoColombo

    Hi StefanoColombo, 

    If you are using a DNAT rule , then you may take a tcpdump of the connection used to recreate this issue. 

    the command to monitor the traffic.

    console >drop 'host <src_ip>

    console>tcpdump 'host <src_ip>

    You may try disabling Strict policy and check if that reduces the delay and may need to toggle and check again.

    console >set advanced-firewall strict-policy off/on

    console> set advanced-firewall tcp-seq-checking off/on

  • 0 in reply to Aditya Patel

    What is the impact of disabling these ?

    console >set advanced-firewall strict-policy off/on

    console> set advanced-firewall tcp-seq-checking off/on

     

    what would you expect me to see from tcpdump , live ?

  • 0 in reply to StefanoColombo

    Stefano,

    from the XG CLI admin guide:

    • tcp-seq-checking

      Every TCP packet contains a Sequence Number (SYN) and an Acknowledgement Number (ACK). Sophos XG Firewall monitors SYN and ACK numbers within a certain window to ensure that the packet is indeed part of the session. However, certain application and third party vendors use non- RFC methods to verify a packet's validity or for some other reason a server may send packets in invalid sequence numbers and expect an acknowledgement. For this reason, Sophos Firewall offers the ability to disable this feature. Default – ON

    For strict policy, I am not sure what checks are disabled.

    From the TCPDUMP you should see wrong Sequence numbers, wrong ACK sequences or even RST flagged packet.

    Regards

  • 0 in reply to StefanoColombo

    I've solved increasing this parameter to 90 sec ( hope this can help someone in the future ) 

    set http_proxy response_timeout 90

  • 0 in reply to StefanoColombo

    Hi StefanoColombo,

     As Luk have suggested we need to check if there are any connections/packets dropped or not. Use the command below

    option 4 ->console >drop 'host <src_ip>

    If strict policy is set off or valid traffic after strict policy checking are submit to Bypass Firewall Module. Bypass firewall module will check for source IP and destination IP for all packets and if IP found in bypass firewall Rule they mark packet not to send to Connection tracking module and firewall Module. These packets were directly sent to routing module. Base on routing module these packets were sent for appropriate destination interface.

Reply
  • 0 in reply to StefanoColombo

    Hi StefanoColombo,

     As Luk have suggested we need to check if there are any connections/packets dropped or not. Use the command below

    option 4 ->console >drop 'host <src_ip>

    If strict policy is set off or valid traffic after strict policy checking are submit to Bypass Firewall Module. Bypass firewall module will check for source IP and destination IP for all packets and if IP found in bypass firewall Rule they mark packet not to send to Connection tracking module and firewall Module. These packets were directly sent to routing module. Base on routing module these packets were sent for appropriate destination interface.

Children