ASP.NET Applications behind USG Firewalls show USG local IP instead of web client public IP

SiSZyComm
SiSZyComm Posts: 10
First Anniversary First Comment
edited December 2022 in Security
what a subject!

dear forum,

We exchanged our old firewalls with a USG 110 and 210 firewalls.

Since the exchange we get on ASP.NET web applications on IIS 7 or IIS 8.5 as client web address the IP address of the USG firewall.

NAT is working fine: whenever I access the web from the IIS I get the specified public IP address for my web server.

But whenever a client accesses a service on our web server we don't get his public ip address (e.g. 333.913.328.999) but the local ip address of our usg (e.g. 192.168.1.1).

why is that? we didn't change any code.

I've attached a simple sample asp.net code file which running displays:

HTTP_X_FORWARDED_FOR is empty!

Running same asp.net code behind a different firewall on "same" IIS 7 / IIS 8.5 results in the displaying the web clients public ip address.

Therefor I assume I have to adjust something on my USG 110 / 210 firewalls. But I have no idea what.

which configuration am I missing no my USG?

thank you
Sven
 




All Replies

  • jasailafan
    jasailafan Posts: 189  Master Member
    First Anniversary 10 Comments Friend Collector First Answer
    Is NAT loopback enabled in the NAT rule?
  • Yes, NAT loopback is enabled (Edit NAT > related settings > "Enable NAT Loopback")

    Port Mapping Type > Classification = 1:1 NAT

    Mapping Rule > Port Mapping Type = any

    any other ideas?


  • mMontana
    mMontana Posts: 1,298  Guru Member
    First Anniversary 10 Comments Friend Collector First Answer
    edited December 2022
    SiSZyComm said:
    Port Mapping Type > Classification = 1:1 NAT

    Why this kind of Port Forwarding and not a service/service group one? Are you using more than one public address?

  • mMontana said:
    SiSZyComm said:
    Port Mapping Type > Classification = 1:1 NAT

    Why this kind of Port Forwarding and not a service/service group one? Are you using more than one public address?


    i do not understand your question, but yes, we do use more than one public ip address like this:

    666.333.33.33 WAN USG, 192.168.1.1 LAN
    666.333.33.33 1:1 NAT 192.168.1.100 (e.g. ASP.NET Application Server)
    666.333.33.34 1:1 NAT 192.168.1.101 (e.g. Exchange)
    666.333.33.35 1:1 NAT 192.168.1.102 (e.g. Citrix)
    666.333.33.35 1:1 NAT 192.168.1.103 (e.g. SharePoint)
    ...

    The sole problem we have is, that retrieving the client public ip address (e.g. 333.22.22.583) in .NET Code (e.g. System.Web.HttpContext.Current.Request.ServerVariables("HTTP_X_FORWARDED_FOR") ) returns the LAN IP-Address of our USG (12.168.1.1) and not the desired client public ip address.

    External/Internal IP is just an IP-Address-Object of Type "Host".

    We do have an additional Routing Policy regarding this NAT:


    Source Address and SNAT are the same IP Address Objects as in the NAT-Rule.

    I thank all of you for looking into this.

    Sven




  • jasailafan
    jasailafan Posts: 189  Master Member
    First Anniversary 10 Comments Friend Collector First Answer
    For 1:1 NAT rule, you don't need to create extra policy route. The policy route has higher priority than 1:1 SNAT. Disable your additional Routing Policy and check it again.
     
  • this is strange: disabling our Policy Route didn't change anything. But thanks to your suggestion we got help from an external and she suggested to adjust "source address", "destination address" and "Source Network Address Translation" as follows (compare to my previous post):
     

    old route policy config (not working):
    • Source Address: internal LAN IP-Address of our web server (e.g. 192.168.1.100)
    • Destination Address: any
    • Source Network Address Translation: designated public IP Address of our web server (e.g. 666.333.33.33)
    new route policy config (working):
    • Source Address: any
    • Destination Address: designated public IP Address of our web server (e.g. 666.333.33.33)
    • Source Network Address Translation: none

    This works! It seams we need this routing policy nonetheless but slightly adjusted. I'm not yet 100% convinced this is the has-to-be configuration. But at the moment with this adjusted routing policy and the 1:1 NAT rule from my post of Decemeber 12th, we got the desired result.

    Sven



Security Highlight