at first, do you really want to create a new log report on MWG or would it also be enough to create a query/report on CSR (Content Security Reporter or any other reporting solution) where you push the access log to and then simply create a query with filter for NAT IP?
By default, there is an access log created which should contain all information (all connections/requests etc.) but there is no marker which identifies the connections made with NAT IP.
Further, MWG does not know if the client IP address of an incoming connection is the real client IP or the NAT etc. So you have to "tell" this the MWG through creating a specific criteria when writing a specific log.
Under "Log handler" you can create a new rule with criteria "Client.IP equals <NAT IP>" or "Client.IP is in list <list of NAT IPs>" and then you create/write a new/dedicated log with the information/fields that are required (e.g. date/time, username, client IP (which will only be the NAT), URL, etc.).
Please notice, if X-Forwarded-For header is sent to MWG (which normally contains original client IP), then property Client.IP will contain original client IP address and you have to use property Connection.IP which should then contain the NAT IP (source IP address from header).
I would suggest to setup a dummy rule with those 2 properties with action Continue and no event, start a rule trace and then perform some traffic with different clients to check how the MWG sees this incoming connection and which IP address is written in which of the 2 properties.
If you have tested this and identified correct property/IP, then you can setup a new logging rule etc.
Let us know if you have further questions.
okay, this can be possible if the connection includes the XFF header with original client IP address. If this header is available, MWG will automatically use this value as client IP instead of the connection IP.
Please have a try and type in original client IP and request some websites and you should see the incoming traffic. If this is the case, you probably would need to work with Connection.IP property when writing new log.
As mentioned before, you can create a dummy rule to check both entries of these properties like:
Client.IP equals 188.8.131.52 OR Connection.IP equals 184.108.40.206, Action: Continue
Then create rule trace and select the dummy rule and you will see how this rule and both criteria where triggered and its values. Normally, you should see the client.IP contains the original client IP taken from XFF header and Connection.IP should contain the NAT IP.
(not 100% sure without having seen or tested this, but it should work like this)
regarding the rule trace, have you typed in the original client IP and tried again if nothing was shown for NAT IP?
Steps would be:
1. create dummy rule and check for client and connection IP with action Continue
2. create rule trace (try with both, NAT and client IP) and look if rule traces are created
3. check output in dummy rule where you typically should see the NAT IP in connection.IP property and the client IP in client.IP property (normally, XFF header is sent in client connection so that other network devices such as MWG can see actual client IP, means client IP is taken from XFF header and connection IP is the source IP from the connection, of course this only works if XFF header is available and not removed on other network devices between MWG and client)
4. based on this, you can create a report like:
Connection.IP equals <NAT_IP>, event: <report>
In the report, you can then log date/time, URL, user, connection IP and client IP. So you would know, which original client IP has accessed the MWG via NAT IP.
If this information does not help or you have further issues, I would suggest to open a SR to actually work with debug data (feedback file, rule trace, tcpdump). This information might be necessary but should not be uploaded here in community, therefore SR would be recommended.