Thread Info
  • State Verified Answer
  • +1 person also asked this people also asked this
  • Locked Locked
  • Replies 4 replies
  • Subscribers 4 subscribers
  • Views 18617 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

WAF - url hardening errors

Louis-M

I'm not 100% sure what is happening here so hopefully somebody could share some light on it.

Virtual webserver A (1.1.1.1 mywebserverA.mydomain.com) maps to internal server A (10.1.1.1 http) using reverse Authentication

Virtual webserver B (1.1.1.2 mywebserverB.mydomain.com) maps to internal server B (10.1.1.2 https)

 

Sometimes when I go to access https://mywebserverB.mydomain.com, I get a 403 "you do not have permission to access these pages on your server"

When I look in the logs, the reason it is throwing up this error is because it's trying to go to https://mywebserverA.mydomain.com and the url hardening throws an error due to this.

 

2017:02:28-06:45:28 gw01-1 reverseproxy: [Tue Feb 28 06:45:28.632056 2017] [url_hardening:error] [pid 1948:tid 4129786736] [client 88.95.200.45:38427] Hostname in HTTP request (mywebserverB.mydomain.com) does not match the server name (mywebserverA.mydomain.com)

 

A couple of minutes later, it seems to play ball and behave itself. I'm not sure why when I request webserver B, the UTM tries to go to webserver A



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

    Louis, did this problem persist or just go away on its own?

    Cheers - Bob

     
    Sophos UTM Community Moderator
    Sophos Certified Architect - UTM
    Sophos Certified Engineer - XG
    Gold Solution Partner since 2005
    MediaSoft, Inc. USA
  • 0 in reply to BAlfson

    Hi Bob, I'll have to do a little more testing as I'm trying to replace a Cisco ASA 5510 which is solely used for SSL clientless vpn. This is in a live environment and the Sophos is running side by side. This is the last part as I've already retired the main ASA cluster and replaced with a SG310 cluster and all is well.

    This particular part is a little hit and miss at the moment. One minute it works, the next it doesn't. And that's only with 2 urls. I need at least 20 to reverse proxy some server links on our main sharepoint site that point to our other servers.

     

    UPDATE

    just tried it again and getting the same errors

    Hostname in HTTP request (serverB.mydomain.com) does not match the server name (serverA.mydomain.com)

    *** above FDQN's renamed as I'm not allowed to publish them. ServerA & ServerB are totally named differently ***

     

    The strange bit is when I type https://myserverB.mydomain.com, I would expect it to go to there but the logs show it's trying to go to https://myserverA.mydomain.com

  • +1 in reply to Louis-M

    Hi Louis,

    this is really strange. :-(

    Are you sure that there are no DNS issues in your environment? Do you have more than one DNS servers that you can shutdown them one by one to exclude this kind of problems?

     

    Greets,

    Flo

  • +1 in reply to Florian Bartsch

    Hi Florian,

    I think I may have solved the issue and it was indeed a dns issue.

    When I was replacing our Cisco's last year, I put the external dns name into the dns request routing on the UTM.

    So externally, my request would have gone to ISP > UTM > which then routed the dns for myexternaldomain.com to my internal dns servers. Now the internal ones had the internal domain & the external domain ie so mobile users who had the external link could use the internal ip when within the network. The usual stuff.

    My mistake here was to put the request routing for the external domain into the UTM which caused the UTM to translate any request going to myexternaldomain.com to the internal ip

    Any external user within our network would first hit out internal dns servers which have our external domain entered so that is fine. By entering the request routing into the UTM for myexternaldomain.com, anybody on the outside would have been getting resolved to the UTM which was then getting mixed up because it was forwarding the request onto the internal dns where as ultimately, it should have forwarded it onto the ISP and got the real external IP.

    Took a little bit of thinking about as the WAF logs didn't really show anything apart from it going to the wrong url but after clearing all the dns caches everywhere and removing the external to internal dns request routing, it's finally working. Fingers crossed.....

Reply
  • +1 in reply to Florian Bartsch

    Hi Florian,

    I think I may have solved the issue and it was indeed a dns issue.

    When I was replacing our Cisco's last year, I put the external dns name into the dns request routing on the UTM.

    So externally, my request would have gone to ISP > UTM > which then routed the dns for myexternaldomain.com to my internal dns servers. Now the internal ones had the internal domain & the external domain ie so mobile users who had the external link could use the internal ip when within the network. The usual stuff.

    My mistake here was to put the request routing for the external domain into the UTM which caused the UTM to translate any request going to myexternaldomain.com to the internal ip

    Any external user within our network would first hit out internal dns servers which have our external domain entered so that is fine. By entering the request routing into the UTM for myexternaldomain.com, anybody on the outside would have been getting resolved to the UTM which was then getting mixed up because it was forwarding the request onto the internal dns where as ultimately, it should have forwarded it onto the ISP and got the real external IP.

    Took a little bit of thinking about as the WAF logs didn't really show anything apart from it going to the wrong url but after clearing all the dns caches everywhere and removing the external to internal dns request routing, it's finally working. Fingers crossed.....

Children
No Data
Unfiltered HTML