SD-WAN

I'm trying to setup a service for an application that resides in a data center behind an internet facing 128T router (public IP of 74.200.44.20/32). I would like to configure an ACL to only allow traffic from a specific subnet to access this application (and to deny all other sources).

 

In my example I've created a public service called ""public-service"". ? The scope is set to `public`. I want to forward TCP ports 22, 80 and 443 to a specific server at 172.100.128.20/32. I also only want to allow traffic sourced from the 161.97.200.60/24 subnet to reach this server.

 

I believe I first need the service definition:

service public-service name public-service enabled true scope public security aes2 ¾ transport tcp protocol tcp ¾ port-range 22 start-port 22 exit ¾ port-range 443 start-port 443 exit ¾ port-range 80 start-port 80 exit exit address 74.200.44.20/32 ¾ access-policy 161.97.200.60/24 source 161.97.200.60/24 permission allow exit share-service-routes false exit

I believe I also need a service-route that performs a destination NAT from the public IP address to the server hosting the application:

service-route dnat-to-public-service name dnat-to-public-service service-name public-service nat-target 172.100.128.20 exit

Several questions:

1 - Is this the optimal configuration to support this type of service?

2 - What role, if any, does the `security` parameter play in the service definition?

3 - Does the `access-policy` of `allow` inherently deny all sources outside of the specified subnet?

 

Thank you!

 

P.S. The public IP's in the example are fabricated...

I did some preliminary testing and was able to achieve the desired results using two access policies for this service. I had one access-policy setup to deny 0.0.0.0/0 and one to allow traffic from 161.97.200.0/24 (incorrectly referenced the /24 in my initial config above).

 

The more granular policy of allowing only the /32 address worked as well if I wanted to lock it down to a specific source.

 

There may be additional ways to accomplish this, but this worked for my initial testing (running 3.1.7).

Yeah Jason Plante I was going to recommend something similar. Having the service set to public (along with a route) would give it a FIB entry for packets arriving that don't belong to any other tenant...then it would flow through to the access policy lookup. Having that deny 0.0.0.0/0 + allow 161.97.200.0/24 would set that table up to do what you are describing.

 

An alternative method if you wanted to leverage a topology you had established with neighborhoods, would be to actually define 161.97.200.0/24 as a tenant for a given neighborhood, and give that tenant access to the service (with it set to private). Then packets arriving from 161.97.200.0/24 on an interface configured to be in that neighborhood, would belong to an allowed tenant.

 

Both seem like perfectly valid approaches.

I agree with {@005o00000025H8kAAE}, they are both perfectly valid. The end result is slightly different between using an ACL to deny access and having no route. In the example you?ve crafted above, there?ll be a FIB entry for the service for 0.0.0.0, and the 128T will drop inbound packets ?later? in the processing chain due to your access-policy. This will cause the 128T to appear to be deaf to the inbound session request, If you were to use the alternate approach Reid proposed, there?d be no FIB entry for folks that sent packets in but weren?t part of the tenant specified by 161.97.200.0/24 in your ?public neighborhood,? which would result in the 128T responding with an ICMP No Routes Found. There are pros and cons to each approach. The approach in the OP is probably more appealing to security folks. The private service approach may be more appealing if you end up having this same policy on many different services, with a list of permissible sources, as it?ll wind up with a more compact, readable configuration.