Guest User!

You are not Sophos Staff.

Thread Info
  • State Not Answered
  • Locked Locked
  • Replies 17 replies
  • Subscribers 3 subscribers
  • Views 124275 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

Bypass WAF for specific URL

Gary Burch

I have a few HTTPS sites successfully published through my UTM Firewall (mostly Exchange Admin Console/Outlook Web Access).

I'm now trying to set up another application, using a different domain name, but the Web Application Firewall log is reporting the following error:

[proxy_http:error] [pid 35268:tid 4122188656] (-102)Unknown error 4294967194: [client <external client IP>:50024] AH01095: prefetch request body failed to <Application server IP in DMZ>:443 (<Application server IP in DMZ>) from <external client IP> ()

I've created firewall rule to allow the traffic (with logging enabled), but nothing is showing up in the firewall logs.

Is there any way I can configure UTM not to scan traffic bound for this particular domain/URL, and just pass it straight through?  Obviously, I can't create a NAT rule, as it will break the other HTTPS sites currently working through the UTM.

Or, is there some way I can disable this 'prefetch' attempt that UTM is attempting?

 

Many thanks



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

    Hi Gary, 

    show us few more log lines from the reverseproxy.log. Alongside, how about configuring exception for "web request matching this path" and selecting both advance tab options. Does that help?

    Thanks

  • 0 in reply to sachingurung

    Thanks for a quick response.

    Whenever I attempt to connect to this URL, the following two lines are logged in the reverseproxy.log:

    reverseproxy: [Tue Feb 21 16:41:28.897685 2017] [proxy_http:error] [pid 35268:tid 3903978352] (-102)Unknown error 4294967194: [client <External Client IP>:50126] AH01095: prefetch request body failed to <Server DMZ IP>:443 (<Server DMZ IP>) from <External Client IP> ()


    reverseproxy: id="0299" srcip="<External Client IP>" localip="<UTM External IP>" size="384" user="-" host="<External Client IP>" method="SSTP_DUPLEX_POST" statuscode="413" reason="-" extra="-" exceptions="SkipAntiVirus, SkipURLHardening, SkipFormHardening, SkipFormHardeningMissingToken, SkipCookieSigning, SkipThreatsFilter" time="123430" url="/sra_{BA195980-CD49-458b-9E23-C84EE0ADCD75}/" server="<public FQDN>" referer="-" cookie="-" set-cookie="-"

    I've gone through a few variations of the exception (under Webserver Protection -> Web Application Firewall -> Exceptions), it's current configuration is:

    Web clients coming from these source networks:  Any IPv4

    Skip these checks:  All except for 'Block clients with bad reputation'

    Skip these categories:  All

    Advanced:  'Never change HTML during Static URL Hardening or Form Hardening' and 'Accept unhardened form data' both checked.

  • 0 in reply to Gary Burch

    Gary, have you tried creating a separate Virtual Server to have access to this FQDN pass through with no Filter in place?  If that works, then you can add protections until the access fails.

    Cheers - Bob

  • 0 in reply to BAlfson

    Hi,

    Many thanks for your feedback, I'm afraid I haven't been able to look at this for a few days.

    There is a separate Virtual Server under Webserver protection -> Web Application Firewall -> Virtual Webservers, with the certificate attached for this FQDN.  Is that what you're referring to?  This Virtual Webserver is using a firewall profile in 'Monitor' mode, with all the options unchecked under 'Hardening & Signing' and 'Filtering'

    Have I missed somewhere where I can configure the filtering to be bypassed?

     

    Many thanks

  • 0 in reply to sachingurung

    Please see below screenshot.  Does this help at all?

     

  • 0 in reply to Gary Burch

    You shouldn't need an Exception, Gary.  Just start with ::No profile:: selected.  I suspect the issue is with your Virtual Server configuration.  Is there anything interesting in the Web Application Firewall log?

    Cheers - Bob

  • 0 in reply to BAlfson

    Hi Bob,

    I've changed the firewall profile to ::No profile:: and tested again, same results as before.

    There are two lines logged in the web application firewall whenever I attempt to access this service - they're in my post above on 21 Feb 2017 4:51 PM.

     

    If I disable the interface on the Server in the DMZ where I want UTM to forward this traffic to, I get different errors in the logs to indicate that it can't connect to it.  From the client end, it appears exactly the same as when the server is running though.

     

    I know that the actual server is working, as I can connect a device (the same client I'm testing from) onto the same subnet as the server, and it connects without issues.

  • 0 in reply to Gary Burch

    It sounds like the only solution is to change the port used for that access or to use an Additional IP so that a DNAT is possible.

    Cheers - bob

  • 0 in reply to BAlfson

    Unfortunately, neither of these options are possible.

     

    Many thanks for the input.

  • 0 in reply to Gary Burch

    What does Sophos Support say about this, Gary?

    Cheers - Bob

  • 0 in reply to BAlfson

    I'm running a home license, so I don't think I'm able to raise tickets with Sophos Support.

  • 0 in reply to Gary Burch

    You're right, Gary, you can't.  At this point, you need to get an additional IP from your ISP.

    An alternative would be to find a friend that will accept inbound HTTP traffic and Full NAT it over to you on a different port.  You can then capture the packets with a DNAT.  Your friend has to use a Full NAT though because the response back from your web server must come from his IP.

    Cheers - Bob

Reply
  • 0 in reply to Gary Burch

    You're right, Gary, you can't.  At this point, you need to get an additional IP from your ISP.

    An alternative would be to find a friend that will accept inbound HTTP traffic and Full NAT it over to you on a different port.  You can then capture the packets with a DNAT.  Your friend has to use a Full NAT though because the response back from your web server must come from his IP.

    Cheers - Bob

Children
No Data