How to filter Office 365 in source NAT?

cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 
Announcements

How to filter Office 365 in source NAT?

Hello,

We have a specific requriement to map Office 365 traffic to a specific source NAT to ensure we don't exceed the port limitation. The only way we can think of doing this is to include all the Office 365 IP address ranges in the destination of the source NAT configuration.

 

Has anyone accomplished this in a more elegant way? It is less than ideal to have a manual process to check an update Microsoft IP ranges as they change.

 

There is no application or URL match under the source NAT configuration, which would have been ideal. We are running 7.0.9, 

 

Any ideas are welcome..

Thanks!

1 accepted solution

Accepted Solutions

We did think about this option. There is a bit more complexity involved as the new interface/subnet needs to be provisioned on the other end and then redistributed into dynamic routing protocols, so this will eb a last resort.

View solution in original post

4 REPLIES 4

Cyber Elite
Cyber Elite

a bit of a longshot: how about setting up a Policy Based Forwarding policy for the office365 application so it goes out of a different interface (you could use a different physical interface or a subinterface). you can then create a NAT rule that matches the destination interface of the PBF allowing you full control over the rest of the NAT features

Tom Piens
PANgurus - Strata specialist; config reviews, policy optimization

L6 Presenter

@chaminda.kiriwattuduwa Not sure if this fits for you guys, but a a portion of our O365 deployment we have EOP.

 

https://technet.microsoft.com/en-us/library/dn163583(v=exchg.150).aspx

 

Supposedly it's a pretty static list:

 

" Changes to the list of IP addresses are rare, and are communicated in advance"

 

 

 

Looks like there have been 3 changes each year - https://technet.microsoft.com/en-us/library/dn163581(v=exchg.150).aspx

We did think about this option. There is a bit more complexity involved as the new interface/subnet needs to be provisioned on the other end and then redistributed into dynamic routing protocols, so this will eb a last resort.

Thanks, looks like we have to go down this path as well.

  • 1 accepted solution
  • 3819 Views
  • 4 replies
  • 0 Likes
Like what you see?

Show your appreciation!

Click Like if a post is helpful to you or if you just want to show your support.

Click Accept as Solution to acknowledge that the answer to your question has been provided.

The button appears next to the replies on topics you’ve started. The member who gave the solution and all future visitors to this topic will appreciate it!

These simple actions take just seconds of your time, but go a long way in showing appreciation for community members and the LIVEcommunity as a whole!

The LIVEcommunity thanks you for your participation!