[strongSwan] Policies should be available in Kernel even though SA is not established!

Daniel Mentz danielml+mailinglists.strongswan at sent.com
Wed Feb 17 09:23:27 CET 2010

ashish mahalka wrote:
> establishes SA b/w the peers, it should over-write those discard
> policies and install ipsec policies in the kernel. Is this possible ?

Hi Ashish,

sorry, but I do not like this idea much. With your design, both, 
strongSwan and your shell scripts access the policy database. I'm afraid 
that this will end up in a complete mess. I suggest that you either have 
strongSwan *or* your shell scripts manipulate the SPD.

> How would I know the reqId of the strongswan's connection ?

I guess you could just temporarily set installpolicy=yes and find out by 
executing "ip xfrm policy" what reqids strongSwan allocates for each 
individual connection. However, from looking at the source code, I get 
this feeling that those IDs might change if you swap the order of the 
connections in ipsec.conf or if you add new connection definitions.

I'm not exactly sure what you are trying to achieve. I guess you want to 
make sure that none of those IP packets that should be protected, leaves 
the gateway unencrypted. From my experience, I suggest to use some 
iptables rules in combination with the policy match.

Here are the rules that I crafted for our gateway. Maybe you can take 
advantage of these:

iptables -A FORWARD -s -m policy --dir out --pol ipsec 
iptables -A FORWARD -d -m policy --dir in --pol ipsec -j 

# Do not forward packets to or from MUCDMZ (Muenchen DMZ) if ipsec is off
iptables -A FORWARD -d -j REJECT --reject-with 
iptables -A FORWARD -s -j REJECT --reject-with 

The idea is basically to accept traffic that is secured by IPsec. A 
subsequent rule makes sure that traffic that did not match the IPsec 
rule will be rejected.

Does this help?


More information about the Users mailing list