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 192.168.10.0/24 -m policy --dir out --pol ipsec 
-j ACCEPT
iptables -A FORWARD -d 192.168.10.0/24 -m policy --dir in --pol ipsec -j 
ACCEPT

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

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?

-Daniel


_______________________________________________
Users mailing list
Users@lists.strongswan.org
https://lists.strongswan.org/mailman/listinfo/users

Reply via email to