Related IP is internal LAN adapter RSS

1

I've recently installed a new Exchange 2016 server and migrated the ORF config from our old Exchange 2010 server to it.
I followed the correct procedure to perform the migration.

Aside from a few anomalies, most of it looks to be working correctly, apart from the related IP is now being listed as the IP of the LAN adapter on the 2016 Exchange server, rather than the IP of the sending server.
This only happens when emails are whitelisted.
If an email is rejected, the correct IP of the sending server is listed.

Can anyone shed any light on this?

by gavpop 3 months ago
2

@gavpop: Hello gavpop,

There are two things to remember when it comes to analyzing the ORF logs:

1) Before Arrival, ORF considers the remote peer IP address of the SMTP connection as the sender and use the connecting IP for its IP-based tests. If the IP address is on the Intermediate Host List (https://vamsoft.com/support/docs/orf-help/5.5/adm-intermediatehostlist), ORF skips the Before Arrival tests, and waits for the whole email to arrive in order to determine the original sender address from the available message header (https://vamsoft.com/support/docs/orf-help/5.5/headeranalysis).

2) The IP address recorded in the “Related IP” field of the ORF log should be interpreted as the IP address that is related to and relevant to the logged *filtering event* - which is not necessarily the source IP of the incoming email. Unless the event is directly related to an IP-based test, such as the IP blacklist, IP Whitelist or the SPF Test (etc.), the Related IP field will show the IP address of the last delivery hop, and not the IP of the sending server.

I hope this helps.

by Daniel Novak (Vamsoft) 3 months ago
(in reply to this post)

3

This definitely isn't working correctly and isn't working as it did on my previous Exchange 2010 server.
On Exchange 2010, it would list the sending serving IP address regardless of which test was initiated.

Because of this, some tests are failing to fire. For example, we received some SPAM this morning that should have hit the keyword blacklist but didn't. It didn't hit it because after greylisting test had completed, the email was whitelisted by the IP whitelist.

Here is the chain...
5.5 REGISTERED Verbose no-sv-exch-01.paleu.com MSEXCHANGE 24/07/2018 17:19 Whitelist Information On Arrival 192.0.0.174 #### Your Bristol Store invoice is ready Whitelisted by the IP Whitelist.
5.5 REGISTERED Verbose no-sv-exch-01.paleu.com MSEXCHANGE 24/07/2018 16:09 Blacklist Information Reject Before Arrival 202.162.238.13 #### Temporarily rejected by the Greylisting Test.
5.5 REGISTERED Verbose no-sv-exch-01.paleu.com MSEXCHANGE 24/07/2018 15:56 Blacklist Information Reject Before Arrival 202.162.238.13 #### Temporarily rejected by the Greylisting Test.
5.5 REGISTERED Verbose no-sv-exch-01.paleu.com MSEXCHANGE 24/07/2018 15:51 Blacklist Information Reject Before Arrival 202.162.238.13 #### Temporarily rejected by the Greylisting Test.



On our old server, the chain would look like this...
5.5 REGISTERED Verbose prominent-mail.paleu.com MSEXCHANGE 7/13/2018 11:03:56 AM Pass Information On Arrival 167.89.34.30 bounces+719740-c125-glasgow= #### ⭐ ⭐ ⭐ ⭐ ⭐ How many stars would you give www.morplan.com? Email passed checks.
5.5 REGISTERED Verbose prominent-mail.paleu.com MSEXCHANGE 7/13/2018 10:48:48 AM Blacklist Information Reject Before Arrival 167.89.34.30 bounces+719740-c125-glasgow= #### Temporarily rejected by the Greylisting Test.
5.5 REGISTERED Verbose prominent-mail.paleu.com MSEXCHANGE 7/13/2018 10:40:24 AM Blacklist Information Reject Before Arrival 167.89.34.30 bounces+719740-c125-glasgow= #### Temporarily rejected by the Greylisting Test.
5.5 REGISTERED Verbose prominent-mail.paleu.com MSEXCHANGE 7/13/2018 10:36:17 AM Blacklist Information Reject Before Arrival 167.89.34.30 bounces+719740-c125-glasgow= #### Temporarily rejected by the Greylisting Test.


As you can see, on the old server, even after all tests and eventually being whitelisted, it still logs the sending server IP.

by gavpop 2 months ago
4

@gavpop: Hello gavpop,

The email was whitelisted because the IP 192.0.0.174 was - manually - added - by one of the admins to the IP whitelist of ORF, hence the message "Whitelisted by the IP Whitelist". Find the IP address on the IP Whitelist page (of the ORF Administration Tool) and remove it from the list.

Considering that IP address 192.0.0.174 is a reserved special purpose address that is not routed publicly, I assume it belongs your organization. Do you use the 192.0.0.0/24 range as alternative to the standard 192.168.0.0/24 private intranet range? Please note that IANA has specified the following three blocks of the IP address space for private intranet use (in RFC1918: https://tools.ietf.org/html/rfc1918):

Class A: 10.0.0.0 - 10.255.255.255 (10/8 prefix)
Class B: 172.16.0.0 - 172.31.255.255 (172.16/12 prefix)
Class C: 192.168.0.0 - 192.168.255.255 (192.168/16 prefix)

Emails sent directly from the above ranges are automatically excluded from ORF filtering to avoid accidental blacklisting of internal and outgoing emails. Moreover, if you check the 'Intermediate Hosts' page in the ORF Administration Tool (Filtering > Intermediate Hosts), you will notice that the aforementioned IPv4 blocks are already pre-added and "burnt onto" the list (i.e. they cannot be removed). This is because ORF uses this list to figure out where your network perimeter ends and where the internet begins, while analyzing the message header of an incoming email to find the source IP of it (see 'Header Analysis" explained at https://vamsoft.com/support/docs/orf-help/5.5/headeranalysis). Consequently, it is crucial that you keep the intermediate host list up-to-date. It should include the IP address (or range) of any host that belongs to your organization and can relay emails to the ORF server - unless, it has a standard Class A, B, C private intranet address.

So, in short, if 192.0.0.174 does belong to your organization, remove the IP address from the 'IP Whitelist' and add it to the 'Intermediate hosts' list of ORF to resolve this issue. Then, save the ORF configuration (Ctrl + S) to apply the new settings.

On a final note, make sure that your firewalls and mail-security appliances are configured to leave the "Receieved from:" header fields in the email's message header intact (i.e. do not let them strip those fields). Otherwise, ORF will not be able to determine the correct source IP and will use a wrong IP for its tests.

Le me know if this has helped.

by Daniel Novak (Vamsoft) 2 months ago
(in reply to this post)

New comment

Fill in the form below to add a new comment. All fields are required. If you are a registered user on our site, please sign in first.

Nickname:
Email address (will not be published):
Your comment:

ORF Technical Support

Configuring, installing and troubleshooting ORF.

News & Announcements

Your dose of ORF-related news and announcements.

Everything but ORF

Discuss Exchange and system administration with fellow admins.

Feature Test Program

Feature Test Program discussion. Membership is required to visit this forum.

ORF Beta

Join the great bug hunt of the latest test release.

Customer Service

Stay Informed