How to filter Office 365 in source NAT?

Reply
Highlighted

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!

Tags (2)

Accepted Solutions
Highlighted

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


All Replies
Highlighted
L7 Applicator

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.com
Like my answer? check out my book! amazon.com/dp/1789956374
Highlighted
Cyber Elite

@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

Highlighted

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

Highlighted

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

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 Live Community as a whole!

The Live Community thanks you for your participation!