Blocked or Denied VMware SD-WAN Gateway IP's

Products

• VMware SD-WAN by VeloCloud

Issue/Introduction

Symptoms:
A customer may run into a situation where a  VMware SD-WAN Gateway IP address was placed on a denylist and prevented from sending email or traffic to a legitimate website.

Traffic being routed through the gateways
Unable to access certain or specific websites
Receives no response

Environment

VMware SD-WAN by VeloCloud

Cause

A VMware SD-WAN Gateway is multi-tenant by design, and the nature of a shared IP service is that traffic from one client at one site may be of a kind to raise a flag in one of three primary categories.

The three primary categories are: 

1. SPAM/Email Lists – A service has detected email that matches the criteria for junk/spam passing through a particular Gateway IP. Examples of different services affected:
   • INET deny lists
   • Spamhaus ZEN
2. Categorization Lists – A service uses a list that categorizes IP sources, not based on traffic seen but based on other meta data about the IP.  An example of this would be categorizing all Amazon AWS IPs as ‘public cloud’ based on IP registration information.
3. Activity Based Web Lists -  A service operates a list that uses detection methods by looking at active traffic to deny list an IP.

Resolution

1. SPAM/Email Lists – Email relay servers should not be sending sourced through the Gateway.  Mail can be sent from a client through the Gateway but relay servers should have their own unique IP with forward/reverse DNS that is not through a Gateway.
2. Categorization Lists – We will take no action on sites that block user traffic based on this type of list.  From our experience we are not able to influence the list itself, it is up to individual site owners to change their policy.  These lists also frequently could not be changed.  For example: if we are running a Gateway in AWS then it is correctly categorized as ‘public cloud’ and it is the site owners choosing to block this traffic. Cloud Operations maintains a file that is used to keep a list of sites that should always go direct (not use a Gateway).  This list is outside of the Business Policy and was created specifically for fixing known sites that fall under this kind of list.
3. Activity Based Web Lists --  We do not actively patrol these lists.  Should a customer encounter an issue with this kind of list the customer or partner could raise a Support case.  A support person would link up with Cloud Operations to de-list that Gateway IP.  However, we have a fairly limited means of analyzing the traffic.  Thus, any action taken may only temporarily de-list the IP if we are unable to identify the source of the activity and get it to stop or if it is believed to have stopped but starts again later.  This, unfortunately, is the nature of a shared IP service.

Workaround:

1. SPAM/Email Lists – Mail can be sent from a client through the Gateway but relay servers should have their unique IP with forward/reverse DNS that is not through a Gateway.
2. Categorization Lists – Should Cloud Operations remediation attempts fall outside of the lists the filtering service is using and the customer finds their traffic blocked, the workaround would be to create a business policy that sends the relevent traffic direct and thus bypasses the Gateway.  If the service is blocking all web traffic, then the partner or customer would configure a rule that classifies all web traffic as direct.  If this is only an issue for a particular web site(s) which are using a filtering service, they could configure a business policy to send traffic direct just for that site.  Such a rule should be configured by the IP or subnet of the destination website--as rules using a hostname are not guaranteed to be classified properly 100% of the time.
3. Activity Based Web Lists --  If Cloud Operations is unable to de-list the Gateway IP from service, the workaround would be to create a business policy that sends the relevent traffic direct and thus bypasses the Gateway.  If the service is blocking all web traffic, then the partner or customer would configure a rule that classifies all web traffic as direct.  If this is only an issue for a particular web site(s) which are using a filtering service, they could configure a business policy to send traffic direct just for that site.  Such a rule should be configured by the IP or subnet of the destination website--as rules using a hostname are not guaranteed to be classified properly 100% of the time.

Sample Business Policy Configuration.

Below is a sample Business Policy that will route SMTP (Simple Mail Transfer Protocol) traffic direct.  This rule addresses the issue of email being blocked at a Gateway whose IP is on a deny/block list: