ASP.NET Applications behind USG Firewalls show USG local IP instead of web client public IP
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
0
All Replies
-
Is NAT loopback enabled in the NAT rule?
0 -
Yes, NAT loopback is enabled (Edit NAT > related settings > "Enable NAT Loopback")Port Mapping Type > Classification = 1:1 NATMapping Rule > Port Mapping Type = anyany other ideas?0
-
mMontana said:SiSZyComm said:Port Mapping Type > Classification = 1:1 NATi 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 LAN666.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
0 -
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.
0 -
Dear jasailafanthis 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
1
Categories
- All Categories
- 415 Beta Program
- 2.4K Nebula
- 145 Nebula Ideas
- 96 Nebula Status and Incidents
- 5.6K Security
- 240 USG FLEX H Series
- 268 Security Ideas
- 1.4K Switch
- 71 Switch Ideas
- 1.1K Wireless
- 40 Wireless Ideas
- 6.3K Consumer Product
- 247 Service & License
- 386 News and Release
- 83 Security Advisories
- 28 Education Center
- 9 [Campaign] Zyxel Network Detective
- 3.2K FAQ
- 34 Documents
- 34 Nebula Monthly Express
- 83 About Community
- 72 Security Highlight