External IP shows as internal DMZ IP when using "Remote_Host" HTTP variable

Hi, Mike, and welcome to the UTM Community!

I'm not following your description.  Without a proxy, the only way an External access can traverse the UTM to an internal IP is with a DNAT.  Please show a simple diagram of your topology with IPs noted, perhaps noting what was able to access what that you hadn't intended.

Cheers - Bob

I couldn't have made myself clear

I have:

Cable Modem -> UTM -> Green Network (NIC2) and also -> DMZ Network (NIC3)

I have a webserver on the DMZ

Everything work fine, but

I have code on that server that checks the Remote IP of someone browsing. With the Sophos UTM it always show that remote IP as the UTM's NIC address (ie 192.168.1.1). I want the server to see the ACTUAL external IP address of the browsing user, because I have code on the server that allows access to the INTERNAL network users. Because the UTM is saying everyone is coming from 192.168.1.1 this exposes secret parts of my network (some web pages) to the whole internet

Is there a way to do this?

Mike, please show pictures.  We all work better with raw data.

Cheers - Bob

Not wanting to be "funny" or anything but I don't see how pictures will help. I have told you what rules I have. I don't see how these rules affect what I want to happen anyway

I'm obviously missing the point

Putting it another way then, what NAT rule do I need to make, to make the UTM show the external client's IP to the webserver?

No problem, Mike.  I've answered thousands of questions here over the last ten years and the requested pictures would quickly fill in the missing details that you didn't realize you needed to specify.

Cheers - Bob

Okay does this help?

Thanks, Mike, I see now that you aren't using a NAT rule for this.  I'll move this thread to the Webserver Security forum.

If you did have a NAT rule like 'DNAT : Internet -> Web Surfing -> External [www.company.com] (Address) : to 192.168.1.x', you would see the originating IP, but this would cause the bypassing of your Virtual Server for HTTP/S (see #2 in Rulz).  So you were right that a NAT rule wouldn't help you if you want to use Webserver Protection.

When traffic passes through the WAF, it adds the "X-FORWARDED-FOR" header, so that's what you'll need to look for.

Cheers - Bob

That is extremely helpful. Thank you. I have now added code to my site so that header is checked, and it works beautifully

Looking at my existing rules, how could I make (or I should change them so) the email server "see" the actual source IP of the sender/receiver? It is currently seeing ALL users as on the 192 network

Is this a new question, Mike?  I'm not sure what you're asking.

Cheers - Bob

Sort of. You can see my NAT rules. My email server is seeing all connections as coming from the 192. network. I have IP screening on the server, but that is now not working. I'd like the server to see the real connection's IP address, so the IP screen works again

Mike, as I commented above, see #2 in Rulz.  Your DNAT causes inbound traffic to bypass your Virtual Server (DNATs come before Proxies).

Cheers - Bob

Mike, as I commented above, see #2 in Rulz.  Your DNAT causes inbound traffic to bypass your Virtual Server (DNATs come before Proxies).

Cheers - Bob

Thanks. But could I not have NAT rules for only these services POP3/POP3 SSL/SMTP/SMTP SSL so that the mail server could see the real originating IP Address?

I'm lost, Mike.  We're in the Webserver forum, but your last comment is about email.

Cheers - Bob

I see now, Mike.  Yes, you want to use DNATs instead of Full NATs.  If a DNAT doesn't work, then I'll guess that "mail.xxxxx.com" violates #3 in Rulz.  Also, I don't think you want the SNAT - if it's needed as noted, then there might also be a violation of #3 through #5.

Cheers - Bob

I was violating Rule 3 and I have now edited the network definitions and removed the Bound To, and now they all are Bound To <Any>

I have rewitten the NATs to

DNAT. Any -> SMTP -> External WAN (www.mycompany.com). DNAT -> mail.mycompany.com

DNAT. Any -> SMTP SSL -> External WAN (www.mycompany.com). DNAT -> mail.mycompany.com

These work (I can't see whether the email server is seeing the real IP address or not though at the moment)

I still have this

Full NAT. Any -> POP3 SSL -> External WAN (www.mycompany.com). Full NAT ->

Source: Green (Address)

Destination: mail.mycompany.com

If I remove this Full NAT then my email server won't allow me to RECEIVE email and I get an error within Outlook. Turning it back on, and then I can receive okay again

I can also confirm I am now seeing the external originating IP address of the sender. Goooooooood!

So the question really just remains about that Full NAT. Is that okay or is something wrong with it?

I also now realise my original question to you was a load of rubbish! All my NATs are dealing with email, and none of them for the web! How stupid can I be?!

Bearing in mind I do *not* have Web Filtering turned on, what NATs would I need so that my web server would see the originating brower's IP address. I am using the X-FORWARDED-FOR header as a filter, but it would nicer if I could really see the originating address instead of using that header

I have also noticed that the only firewall rules I have for the DMZ (where the web and email server is located) are

Orange Network -> Web Surfing -> Any

Orange Network -> DNS -> Any

There's nothing for email! But email works!?

On Green (where my users are)

Green Network -> Any -> Any