When using Windows IPSec for IP filtering whenever a filter is added you need to have a "mirror" rule (by checking the "Mirrored. Match packets..." tickbox).

Because IPSec Filtering is not stateful, if you don't have this option enabled then you can't communicate in both directions. From this article, I quote:

If you don't mirror your rules, then you can't communicate in both directions. IPsec is not "stateful" in the way that Firewall is - if you have a rule from A to B without the B to A component, then IPsec on A will drop all traffic from B, even if it is the response to request sent by A. That's part of what makes IPsec so difficult to effectively use as a firewall.

If I have a rule that says:

Allow inbound connections to my IP address to port 5666 from any port on remote host

Which would be implemented as:

netsh ipsec static add filter filterlist="NAGIOS NSClient" 
      srcaddr= srcport=0 
      dstaddr=ME dstport=5666 

Would the "mirror" rule be:

Allow outbound connections from my IP address from port 5666 to any port on the remote host

What are the security risks of such a configuration with regards to unwanted traffic?

  • If this is a true stateless rule, does the dstport and srcport function really work or is it possible to craft a request from on srcport 5666 and attempt to access any port on the machine with the above rule? And alternatively does this allow the destination nagios server to use the 5666 srcport and connect to any port on the endpoint device? It seems that may actually be possible even if the rule enforces srcport and dstport
    – Ori
    Jun 9, 2011 at 6:17
  • @ori - thanks for the comment. From my reading since asking the question, I'm under the impression this is also also how IPTables work when not connection tracking. Might have to earn some rep for a bounty :)
    – Kev
    Jun 9, 2011 at 8:02

2 Answers 2


Depending on the service the outgoing port is usually different from the incoming port, and is often randomly assigned. So the mirror would be from any port on localhost to 5666 on the remote host. The risk depends on the IPSec mode: transport or tunneling. I would say the most likely threat would be on availability. In transport mone the destination IP and port are in the clear, So an adversary could attempt to flood the destination port.


I am not familiar with Windows, but in general these IPsec SA rules are completely separate from your firewall. They are meant to associate some IPsec-specific information like the session key with the (stateless) packet stream, so that the gateway knows that it is supposed to decrypt a particular ESP packet, and how. If you want to block "unwanted" traffic, use the firewall on top of that.

The main "risk" is regarding the use of higher layer protocol information such as TCP ports. Packets may be fragmented, so that IPsec is unable to identify which SA a packet belongs to. This is discussed in RFC4301. Since en-route fragmentation is generally discouraged and removed from IPv6, I suppose the best solution is to simply drop all fragments, or not use TCP/UDP port info.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .