When people think of IPsec they think of data encryption but it can also be used to drop packets or allow them without any encryption. It can do this based on the source and destination IP address and port numbers. Which is exactly what a firewall does; so you can use the IPsec feature of VOS as a firewall.
For example, let’s say that you have an internal document service application that listens on *.12345, that is, it listens on port 12345 and will accept a connection from any interface on the module. A new interface has just been added to the module that connects to a supplier’s network. No one from that network should be connecting to the document service. Ideally there is a firewall on the network between the module and the supplier’s network that blocks port 12345 but the principle of “defense in depth” says that a network AND host based firewall is better that just a network firewall.
There are several ways to configure IPsec to drop connections from the supplier’s network. The simplest way is to drop any connection to port 12345 with a destination IP address that corresponds to the new interface. Assuming that the new interface has an IP address of 172.16.1.1 the IPsec policy would look like
{daddr 172.16.1.1 ulp tcp dport 12345 dir in} drop {}
IPsec policies are added with the ipsec_policy_admin command. The default configuration file is >system>stcp>ipsec.conf, but any file can be specified. For this to work the module must not be forwarding packets, otherwise a connect request to another of the module’s interfaces which is received on the 172.16.1.1 interface will be forwarded. Since the destination is not 172.16.1.1 IPsec will allow the connection. It is a good idea to turn forwarding off unless you know that you are actually need to use it. You turn forwarding off with the IP_forwarding command; yes the IP is upper case.
If a new interface was not added and both your internal users and your supplier will use the same interface you must base the policy on the source address, not the destination address. If we assume that the supplier’s network is 192.168.1.0/24, the policy will look like
{saddr 192.168.1.0/24 ulp tcp dport 12345 dir in} drop {}
This of course still allows hosts on the supplier’s network to connect to other services on the module. You can restrict the suppliers to only one service, say the one listening on port 24680 with the following policies
{saddr 192.168.1.0/24 ulp tcp dport 24680 dir in} bypass {}
{saddr 192.168.1.0/24 ulp tcp dir in} drop {}
If the document service only hosts one department’s documents, you can set up a policy that allows connections to port 12345 from only that department’s subnet, say 10.1.1.0/28 with the policies
{saddr 10.1.1.0/28 ulp tcp dport 12345 dir in} bypass {}
{saddr 0.0.0.0/0 ulp tcp dport 12345 dir in} drop {}
The order of the policies is important, if you reverse the order no one will be able to connect to port 12345.
If your CIO requires that he also have access to the documents you can add policy for the CIO’s workstation’s address
{saddr 10.1.1.0/28 ulp tcp dport 12345 dir in} bypass {}
{saddr 10.7.7.7 ulp tcp dport 12345 dir in} bypass {}
{saddr 0.0.0.0/0 ulp tcp dport 12345 dir in} drop {}
As you experiment with IPsec always be sure that you have a policy in place that will allow you a connection, IPsec policies are acted on as soon as they are added, you do not need to reboot or restart anything so an incorrectly typed policy could disconnect you from the module. For example assuming that the IP address of your workstation is 10.1.100.50 I would always place the following policy first in my policy file
{saddr 10.1.100.50 ulp tcp dir in} bypass {}