Thursday, February 20, 2025

Microsoft 365 emails to Gmail getting blocked with 550 5.7.1 errors

 We are using Microsoft 365 for their email service and recently faced an issue where outgoing emails to Gmail were not getting delivered because of the following error :

550 5.7.350 Remote server returned message detected as spam -> 550 5.7.1 [2a01:111:f403:c40f::7 19] Gmail has detected that this message;is likely suspicious due to the very low reputation of the sending;domain. To best protect our users from spam, the message has been;blocked. For more information, go to; https://support.google.com/mail/answer/188131 d9443c01a7336-220d5320c49si112823045ad.160 - gsmtp




Now unless you have some kind of gold-star support with either Microsoft or Gmail, you are stuck with combing through documentation and forums to understand where to even start troubleshooting this error. The usual steps of checking if the domain is listed on spam sites (MultiRBL) and if TestExchangeConnectivity didnt give much insight into the error.

After an hour of going through various forum posts, there was a set of posts with a workaround for a similar situation of emails being sent from Microsoft 365 servers. 


The issue that was identified was that Gmail was blocking emails sent to their servers from IPV6 addresses which were used by Microsoft, as these IPs were not listed on the SPF record of the domain sending the email. 


Now Microsoft documentation recommends to add "include:spf.protection.outlook.com" to the domain SPF record. And technically it "should" resolve to all the outgoing IPs of Microsoft . But I assume in this case the IPv6 server IPs are not resolved here, and so it gets blocked


The rule was to filter emails sent to gmail.com or *.gmail.com and the option to select was the MX record option. The idea here was that DNS resolution using the MX record would force resolution in IPV4 and everything will go well. 
So I setup the rule, and the connector allows for validation, which also worked. 
Great! 
Not really. 
The next day, the problem started again. And this time the connector validation was also failing. 
After some more digging around,  someone figured out a brute force way of updating the SPF record with +ip6:2603:1000::/24  which sort of blanket whitelists the Microsoft IPV6 range. 

The connector validated successfully after this. And outgoing mails to Gmail started working again!

Now we wait and see what Gmail does next :)

Wednesday, September 4, 2024

Fortigate SDWAN with IPSec Site-to-Site VPN and multiple subnets at both sites

Recently, I was tasked with setting up a Site-to-Site VPN between a Fortigate FG100-F in a High Availability (HA) configuration and a FG60-F. Both sites featured dual WAN links configured in an SD-WAN setup, along with multiple VLANs.

I needed to setup multiple VLANs at the branch office Fortigate. I used the VLAN switch feature to create VLANs as sub-interfaces, and then added them to a zone to help with inter-vlan traffic, and for easier firewall policy configuration


To completed the site-to-site VPN links despite consulting the Fortigate documentation, I couldn't find an example that exactly matched this scenario.

After some extensive searching, I found a YouTube video that demonstrated this particular setup. You can watch it here.

YouTube Video Summary

The video, although in Spanish, provides a detailed walkthrough of setting up a Site-to-Site VPN between Fortigate devices in a similar environment. It covers the configuration of dual WAN links, SD-WAN, . Thanks to YouTube's caption feature, I was able to follow along and apply the configurations needed for my setup.

 The video demonstrates how to combine IPsec tunnels with SD-WAN to balance traffic across multiple internet providers. It includes configuring two IPsec tunnels between SP1 and SP2 interfaces of two Fortigates and setting up SD-WAN to use these Fortigates for health checks.

Network Configuration:

  1. Interface Configuration: Assign ISP1 and ISP2 to the "wan internet" zone with their respective gateways.
  2. Routing and Policy Setup: A default route and an internet policy are created for outgoing traffic on LAN

IPsec Tunnel Configuration:

  1. Two IPsec tunnels are configured between the Fortigates with identical settings.
  2. SD-WAN zones are created, and the tunnels are added to these zones.

Loopback Interface and Static Routing:

  1. Create a loopback interface on both Fortigates for monitoring.
  2. Set up static routes using these interfaces.

Policy Configuration and SD-WAN Optimization:

  1. Policies are created to route traffic based on the loopback interface.
  2. SD-WAN rules are configured to route traffic through specific IPsec tunnels based on latency.
  3. The video demonstrates how latency can trigger a switch between tunnels.

This video is an excellent resource for setting up IPsec with SD-WAN on Fortigate devices, especially in scenarios requiring dynamic traffic management based on link performance.

For more details, you can watch the video here.

Troubleshooting the Ping Issue

One problem I encountered was that after bringing the VPN links up ,ping was working from the Branch to the HQ, it wasn't working the other way around. To diagnose this, I used the following Fortigate CLI commands:

di de reset
diagnose debug flow filter addr <src-addr>
di de flow filter proto 1
diagnose debug flow show function enable
diagnose debug console timestamp enable
diagnose debug flow show iprope enable
diagnose debug flow trace start 30
diagnose debug enable

The issue was traced back to the SD-WAN policy rules at the HQ. The policy was configured to 

route all traffic through the WAN links, completely bypassing the VPN interfaces. I had to modify

 the policy to include more specific destinations, which allowed outgoing VPN traffic to be routed 

 correctly through the VPN interfaces.

This setup, while challenging, was a great learning experience, and the YouTube video was 

instrumental in helping me navigate the configuration process.

Monday, August 5, 2024

Handling PDF Size Issues with Protected Files: A Solution Using Microsoft PDF Printer

In a recent project, I encountered a challenge involving a protected PDF file that needed to be included in a multi-page document. The PDF file was around 100 KB, and due to file upload limitations, the entire document had to be under 2 MB. Unfortunately, the protection settings of the PDF prevented it from being added to the multi-page document, citing security restrictions. Additionally, Adobe's PDF printer does not allow printing protected PDFs to a new PDF file—quite a limitation from Adobe!

To work around this, I used the Microsoft PDF Printer, which allowed me to save the file as an unprotected PDF. However, this resulted in a significant increase in file size, ballooning to around 3 MB. Despite attempting various methods to reduce the size, such as using "Optimize PDF," "Reduce PDF Size," and online compression tools, the results were minimal.

After further research, I stumbled upon a forum suggestion to use the "Print As Image" option in the Advanced settings of the Microsoft PDF Printer. This setting effectively reduced the file size to less than 500 KB, well within the required limit.

This technique can be a valuable solution for anyone facing similar issues with protected PDF files and file size constraints.

Wednesday, August 28, 2019

Adobe Acrobat DC Fill & sign Tool missing

Acrobat DC has a nifty tool to allow placing of saved signatures on documents.
After a recent laptop replacement, one user couldnt find the tool to place the signatures needed.
The issue came out to be that Acrobat removes the tool if the language setting of the applications is not set as English only. The application here was set to English & Arabic
You have to go to Edit->Preferences->Language
The Application Language option should be set as English Only
After restarting the program, the Fill&sign option appeared in the Tools Section

Ref: https://forums.adobe.com/thread/1945290

Monday, March 18, 2019

Renew expired Microsoft Exchange Server Auth Certificate

Today our Exchange servers refused to send out emails to the user mailboxes. After going through the logs, Warnings popped up for Exchange OAuth, which said that SMTPReceive connector was failing because of a certificate issue.

So Exchange server installs a server authentication certificate used for Organizational Authentication for itself and other Exchange servers in the organization for intra-site communication, during initial setup

Usually these certificates have a 5 year validity. Upon expiry, some services start failing to work as needed.

Following the link and steps below, i was able to get  the services up and running again.

ref: https://community.spiceworks.com/topic/512374-missing-the-microsoft-exchange-server-auth-certificate

New-ExchangeCertificate -KeySize 2048 -PrivateKeyExportable $true -SubjectName "cn= Microsoft Exchange Server Auth Certificate" -DomainName "*.yourdomain.com" -FriendlyName "Microsoft Exchange Server Auth Certificate" -Services smtp
Do not accept to replace the SMTP certificate when prompted
2. Note the thumbprint of the new certificate. Let us assume it is 7A39541F8DF58D4821967DD8F899B27410F7C081
3. $a=get-date
4. Set-AuthConfig -NewCertificateThumbprint 7A39541F8DF58D4821967DD8F899B27410F7C081 –NewCertificateEffectiveDate $a
Accept to continue despite the fact that the certificate effective date is not 48 hours into the future
5. Set-AuthConfig –PublishCertificate

6. Make sure to remove any potential reference to the previous certificate (which might not exist anymore) by doing Set-AuthConfig -ClearPreviousCertificate.

Access Denied Error on Exchange Management Shell for Exchange 2013

So I tried opening the EMS tool on our Exchange server and i was getting the dreaded Access Denied error. I was also unable to open the Exchange Toolbox.

First issue i noticed was that the server time was off by 6 minutes. So I got that fixed first.

w32tm is the utility used for that.

But that didnt help with the original error

After having enough of going through the logs for errors, and getting fed up of googling, i came across a forum which talked about two modules used by IIS to support authentication on the Powershell Folders under the Default WebSite, and the Exchange Back-End Site

1. WSMAN
2. KERBAUTH

So I left KERBAUTH module on for the Powershell Folder under Default Website and removed WSMAN module from there.
I enable KERBAUTH and WSMAN for the Powershell folder under Exchange Back-End

Both modules have to be native and local when enabled. You can find them under the Configure Native Modules setting on the right side pane

Its better to run iisreset after any change to the IIS settings to be sure of the effects of your changes.


After setting this combo, both EMS and Toolbox started working.



Tuesday, February 26, 2019

QuickParts button in Word 2013

I got to know about a nice feature in Word while looking to solve a problem for a office user.
The user wanted to include customized header and footers so that they could be selected from the header drop down list

The Quickparts button is available under the Insert Tab .

Select the content that you want to replicate later. Click the QuickParts button, choose Save to Quick Part gallery.

Then the building blocks menu comes up, and you can change the Gallery to which it is saved. Choose the Headers Gallery, and give the selection a name to be referenced to later.

Once saved, the selection will be available for all future documents. This however requires you to save these changes to a file called BuildingBlocks.dotx, which Word will ask for when closing the program.

The new custom header will now be available under the Headers drop down menu.

Even footers and tables can be customized in a similar manner.

For further info, please have a look at this link from TechRepublic.
https://www.techrepublic.com/article/office-q-a-adding-custom-headers-to-words-headers-gallery/