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
