Purpose
IPSEC is one of the most useful and sometimes most confusing protocols in modern technology. It seems that to understand IPSEC and its appliance you have to teach you mind to think in a different way than it is used to. Where normally we just look at making a network connection as a ping, with IPSEC we really have to delve into Winsocks and the direction of network packets within a conversation. I am hoping to make some of this a bit easier by using a real example from a TechNet member.
Prerequisites / Suggestions
Before undertaking IPSEC, I would HIGHLY recommend getting a firm understanding of a network socket. A socket is the pairing of SrcIP:Port and DestIP:Port. Here is an article that goes into more detail: Network Ports and Sockets
If you are looking to support IPSEC in an enterprise solution, I would greatly recommend studying the IPSEC Microsoft Press book by Joseph Davis. Of all the IPSEC books I have read it helped me the most to get started.
The Problem
The inspiration for this blog comes from many discussions with customers and colleagues explaining how IPSEC works. The final push for me came from a post I found on TechNet, which I tried to reply to quickly, and grew into this blog. Here is the original question. This is the criteria that the administrator was looking to meet:
– From a number of “Guest” machines:
– Allow AD authentication (outbound traffic to [DC]:389/3268/88)
– Allow Symantec AV communication (outbound traffic to [AV-server]:8014)
– Allow printing (outbound traffic to [printserver]:137/138/139/445)
– Block traffic to private IP-addresses (outbound traffic to [10.x.x.x.x subnet]
– Allow traffic to any other IP. [outbound traffic to x.x.x.x]
Working with IPSEC
Now on to the problem. When working with IPSEC I always find it helpful to remember that the most specific rule wins (Largest onus put on IP Mask. See http://technet.microsoft.com/en-us/library/bb877982.aspx for a detailed discussion on this). Literally, we weigh all of our filters, from most specific to least specific, and look for a match from the top down. Knowing this, I always like to take the most unspecific rule to start with. Following that logic I will flip things as listed above and try to explain why as we go along.
One thing to note here is when entering a filter we only account for one direction of the network traffic. Naturally if we send something out on the network, in most cases we should expect some kind of response back. For that reason Microsoft has included in their IPSEC wizard a check box for “Mirrored. Match packets with the exact opposite source and destination addresses”. This will create an allowance for the return traffic automatically for you. However, whenever I have traffic problems with IPSEC (and use a network sniffer to see it is only one way) the first thing I do is to create the return rule set, by duplicating all my rules, and flipping the SrcIP:Port and DestIP:Port.
With IPSEC, as with many network security protocols, there is a catch-all often called the default rule (MSFT calls it the “Default response rule”). This is the ANY-ANY rule that tells us that if a client with ANY IP over ANY Port tries to talk to ANY IP over ANY Port, do something specific with it (allow/deny/modify). In our case we would set our default rule to ALLOW (Which in the Microsoft world means to disable the default response rule, and create a separate “allow-any” rule) to meet the needs of this statement:
-Allow traffic to any other IP. [outbound traffic to x.x.x.x]
This would net the following rule for us:
Src IP Src Port Dest IP Dest Port Action
ANY ANY ANY ANY Allow
So, the next rule to look at is the super-net of the local network segments (10.x.x.x or 10.0.0.0/8). The Clients, DC, AV-Server, and Print Server are on this network as well. To keep in line with the criteria, we would need to keep these “Guest” clients from sending any data to other 10 net machines. This statement would net this IPSEC rule (Filter + Action) for us:
-Block traffic to private IP-addresses (outbound traffic to [10.x.x.x.x subnet]
Src IP Src Port Dest IP Dest Port Action
My ANY 10.0.0.0/8 ANY Deny
The final three rule sets (rule sets are a grouping of rules that are applied with a similar action, since a single action applies to all the rules in a given set. See the table below for an example), are equally weighted they will each apply from a single IP to a single IP on a specific port. For this example I have given the servers IPs so we can see the rules as we would create them.
Server IP
DC 10.1.1.101
AV 10.1.1.102
PrintServer 10.1.1.103
-Allow AD authentication (outbound traffic to [DC]:389/3268/88)
Src IP Src Port Dest IP Dest Port Action
My ANY 10.1.1.101/32 TCP 389 Allow
My ANY 10.1.1.101/32 TCP 3268 Allow
My ANY 10.1.1.101/32 UDP 88 Allow
-Allow Symantec AV communication (outbound traffic to [AV-server]:8014)
Src IP Src Port Dest IP Dest Port Action
My ANY 10.1.1.102/32 TCP 8014 Allow
-Allow printing (outbound traffic to [printserver]:137/138/139/445)
Src IP Src Port Dest IP Dest Port Action
My ANY 10.1.1.103/32 UDP/TCP 137 Allow
My ANY 10.1.1.103/32 UDP 138 Allow
My ANY 10.1.1.103/32 TCP 139 Allow
My ANY 10.1.1.103/32 TCP 445 Allow
Organized by Rule Sets
It always helps me to see things different ways, so I am going to organize our new rules into the way they would be organized in Microsoft’s “IP Security Polices” module:
– Policy
– Rule: Allow Any-Any
Goal: Allow traffic to any other IP. [outbound traffic to x.x.x.x] Action: Allow Rule: Src IP Src Port Dest IP Dest Port
ANY ANY ANY ANY
– Rule: Block Outbound to10 net
Goal: Block traffic to private IP-addresses (outbound traffic to [10.x.x.x.x subnet] Action: Deny Rule:
Src IP Src Port Dest IP Dest Port My ANY 10.0.0.0/8 ANY
– Rule: 10Net Exemptions
Goal(s): Allow AD authentication (outbound traffic to [DC]:389/3268/88)
Allow Symantec AV communication (outbound traffic to [AV-server]:8014)
Allow printing (outbound traffic to [printserver]:137/138/139/445) Action: Allow Rule:
Src IP Src Port Dest IP Dest Port
My ANY 10.1.1.101/32 TCP 389
My ANY 10.1.1.101/32 TCP 3268
My ANY 10.1.1.101/32 UDP 88
My ANY 10.1.1.102/32 TCP 8014
My ANY 10.1.1.103/32 UDP/TCP 137
My ANY 10.1.1.103/32 UDP 138
My ANY 10.1.1.103/32 TCP 139
My ANY 10.1.1.103/32 TCP 445
Looking at the Resulting Filters
As mentioned earlier, filters are organized from most specific to least. One note here is that the “My” IP address is an exact match, as it represents the computer applying the filter. Following the rules in the aforementioned Cable Guy article (in the “Working with IPSEC” section) here is our resulting filter list (assuming the mirrored box was checked). Remember, when IPSEC is accessing a connection it goes through this list from the top, down.
Src IP Src Port Dest IP Dest Port Action
My ANY 10.1.1.101/32 TCP 389 Allow
10.1.1.101/32 TCP 389 MY ANY Allow
My ANY 10.1.1.101/32 TCP 3268 Allow
10.1.1.101/32 TCP 3268 MY ANY Allow
My ANY 10.1.1.101/32 TCP/UDP 88 Allow
10.1.1.101/32 TCP/UDP 88 MY ANY Allow
My ANY 10.1.1.102/32 TCP 8014 Allow
10.1.1.102/32 TCP 8014 MY ANY Allow
My ANY 10.1.1.103/32 UDP/TCP 137 Allow
10.1.1.103/32 UDP/TCP 137 MY ANY Allow
My ANY 10.1.1.103/32 UDP 138 Allow
10.1.1.103/32 UDP 138 MY ANY Allow
My ANY 10.1.1.103/32 TCP 139 Allow
10.1.1.103/32 TCP 139 MY ANY Allow
My ANY 10.1.1.103/32 TCP 445 Allow
10.1.1.103/32 TCP 445 MY ANY Allow
MY ANY 10.0.0.0/8 ANY Deny
10.0.0.0/8 ANY MY ANY Deny
Any ANY ANY ANY Allow
Throw a Wrench in the Works
Perhaps the hardest part about IPSEC is troubleshooting. The good part is that you never learn more about IPSEC as you do when you are figuring out what went wrong. I am going to take a guess at what was wrong in the forum post that help to inspire this blog. In his post he said:
“Some of the exceptions (AD authentication) works, but not the print server exceptions. Even if we allow all sorts of traffic to the print server, we cannot event ping it It seems as if the rule blocking access to 10.x.x.x. subnet is taking precedence).”
One quick thing to point out, because I often here this from customers, is that when you enable IPSEC ICMP (which ping uses) is automatically accessed. If you want this to be allowed one the 10 net we would need to add this to our Exemption list.
Since I have seen this happen so many times before, I am guessing in his situation one of two things happened. Either during the process of creating the filter for the print server connection the “Mirrored. Match packets with the exact opposite source and destination addresses” check box was not checked, or the resulting filter was not created correctly. In this case either, going back and checking that box, or creating the explicit opposite rule will likely net the desired result.
One other place I commonly see IPSEC deployments fail is when rules step on each other. Most of the IPSEC deployments I deal with are enterprise wide. This means that typically a GPO is used to manage a group of Domain clients/servers. In one instance I may say “do not allow any traffic from 10.1.1.101 to 11.1.1.201” while in another rule I may say “allow all SMB connections to the 10 net from MY IP”. We may have intended to make the later the exemption to the first, but because the first uses Specific IP addresses it will win the conflict and the connections will fail. Looking at it as a filter will make things more obvious:
Src IP Src Port Dest IP Dest Port Action
10.1.1.101/32 ANY 11.1.1.201/32 Any Deny
11.1.1.201/32 ANY 10.1.1.101/32 Any Deny
MY ANY 10.0.0.0/8 445 Allow
This one is a close one as “MY” and /32 are equally rated. The second has a port assigned as well, while the others do not. But, to maintain integrity and scalability, the major onus is put on the uniqueness of the IPs allowed within the filter. If you start from the most general rule first, and then work towards the exceptions to that rule you can always work out a suitable solution.