[strongSwan] how to create a ACL-like system based on certificates?
In order to have fine grained control over the IPsec traffic in our distributed network of host-to-host ipsec connections we would like to create a ACLs-like system. For example all servers should be able to talk to infrastructure hosts (like DNS or backup servers). Only the other storage servers and the few specialized servers accessing the storage system should be able to initiate connections to storage servers. Only the server distributing the search index and the few servers quering the search system should be able to initiate connections to search servers. The monitoring servers should be able to initiate connections to all servers. How could i represent such a system with different types of server certificates (one type per server class) and strongswan configuration? /andreas ___ Users mailing list Users@lists.strongswan.org https://lists.strongswan.org/mailman/listinfo/users
Re: [strongSwan] ACLs-like system to control IPsec traffic
ah, and one server could be in several classes of machines (e.g. search and storage) On Thu, May 13, 2010 at 1:09 AM, Andreas Schuldei schuldei+strongs...@spotify.com wrote: In order to have fine grained control over the IPsec traffic in our distributed network of host-to-host ipsec connections we would like to create a ACLs-like system. For example all servers should be able to talk to infrastructure hosts (like DNS or backup servers). Only the other storage servers and the few specialized servers accessing the storage system should be able to initiate connections to storage servers. Only the server distributing the search index and the few servers quering the search system should be able to initiate connections to search servers. The monitoring servers should be able to initiate connections to all servers. How could i represent such a system with different types of server certificates (one type per server class) and strongswan configuration? /andreas ___ Users mailing list Users@lists.strongswan.org https://lists.strongswan.org/mailman/listinfo/users
[strongSwan] Options available for using a certificate hierarchy or chain
Hello All, We've been using strongSwan as our IPsec solution for a while now (thanks to Martin, Andreas and everyone else who has helped us get this far!). However, we've come up against a problem trying to implement the certificate hierarchy designed by our device-security guys. They've come up with a four-certificate chain solution, i.e. self-certified root CA - class CA - group CA - device certificate. Unfortunately, when I set up one of our devices to use this chain (i.e. root CA on the SeGW, class and group CAs and device certificate on the device), the tunnel is set up fine, but during the initial IKE_AUTH packet sent from the device to the SeGW, the amount of certificate data sent is so large that IP fragmentation kicks in and three IP fragments are sent. We've been warned by our SeGW partners that most SeGWs will not accept IP fragments due to the security risk and that we need to trim back the data sent to make everything fit inside one IP packet. This matches up with one of the answers given in the strongSwan FAQ. Our PKI guys are incredulous about this situation. They wonder how have the IPsec standards managed to get into this situation ?. Can anyone suggest any solutions ? I see that hash-and-url is one proposed solution, and although it is implemented by strongSwan, does anyone have a feel for how widespread that is among other IPsec SeGW implementations ? The PKI guys have grudgingly agreed to cut out one level of CA from the chain, but this would still involve sending one CA plus the device certificate across in the IKE_AUTH packet, and that would still involve IP fragmentation. Another solution would be to preload the intermediate CAs onto the SeGW (as well as our root CA). This works in our lab, when we also use strongSwan as a test SeGW, but I've been informed that most of our customers would NOT be interested in this solution. They want to load ONE root CA onto their SeGW and nothing else. Are there any options left ? Thanks, Graham. ___ Users mailing list Users@lists.strongswan.org https://lists.strongswan.org/mailman/listinfo/users
[strongSwan] strongswan + 3rd VPN router - no traffic
Hi,
I'm planning to replace my old zywall VPN concentrator with a linux box
using strongswan.
I struggling with almost the same problem like Francois with the Cisco
IOS...
The tunnel has been successfully established, but no ping, no traffic at
all. Neither from local, nor from remote.
The linux box has an external IP: 217.27.211.17 on eth0 and
IP:192.168.129.180 on eth1 as internal. there is a server on the internal
subnet (192.168.129.181) which should be reached from the VPN. this server
has a default gateway set to 192.168.129.180 (strongswan linux box internal)
The remote VPN device is a Check Point VPN-1 Edge router. I also tried
with a cheap Draytek Vigor VPN router, and experienced the same situation.
Tunnel established, no traffic.
Strongswan 4.2.9-1
Ubuntu 9.04
/etc/ipsec.conf
# ipsec.conf - strongSwan IPsec configuration file
# basic configuration
config setup
plutodebug=control
# crlcheckinterval=600
# strictcrlpolicy=yes
# cachecrls=yes
nat_traversal=yes
charonstart=yes
plutostart=yes
strictcrlpolicy=no
conn tunnelipsec
type=tunnel
authby=secret
left=217.27.211.17
leftsubnet=192.168.129.0/24
leftnexthop=217.27.211.62
#leftsourceip=192.168.129.180
leftfirewall=yes
right=%any
rightsubnetwithin=192.168.0.0/16
#rightnexthop=%defaultroute
rightfirewall=yes
esp=3des-md5
keyexchange=ike
pfs=no
auto=add
I use right=%any because there will be more than 20 peers and I would like
to use one generic community, that's why i'm using rightsubnetwithin= too.
I have no iptables rules except the automatic rules made by strongswan.
r...@vpn:~# iptables -L -n
Chain INPUT (policy ACCEPT)
target prot opt source destination
Chain FORWARD (policy ACCEPT)
target prot opt source destination
ACCEPT all -- 192.168.180.0/24 192.168.129.0/24policy match
dir in pol ipsec reqid 16389 proto 50
ACCEPT all -- 192.168.129.0/24 192.168.180.0/24policy match
dir out pol ipsec reqid 16389 proto 50
Chain OUTPUT (policy ACCEPT)
target prot opt source destination
I made a NAT rule on 217.27.211.17 to provide internet access for
192.168.129.181.
echo 1 /proc/sys/net/ipv4/ip_forward
/sbin/iptables -t nat -A POSTROUTING -s 192.168.129.0/24 -j SNAT --to
217.27.211.17
iptables -t nat -I POSTROUTING 1 -s 192.168.129.0/24 -o eth1 -m policy
--dir out --pol ipsec --proto esp -j ACCEPT
r...@vpn:~# iptables -L -t nat -n
Chain PREROUTING (policy ACCEPT)
target prot opt source destination
Chain POSTROUTING (policy ACCEPT)
target prot opt source destination
ACCEPT all -- 192.168.129.0/24 0.0.0.0/0 policy match
dir out pol ipsec proto 50
SNAT all -- 192.168.129.0/24 0.0.0.0/0
to:217.27.211.17
Chain OUTPUT (policy ACCEPT)
target prot opt source destination
I'm stucked here. Googled a day and played with leftnexthop=%defaultroute
and %direct, but no changes.
If you have any idea how to proceed...
Thank you
Peter Nadasi
here are my logs below
tail -f /var/log/syslog
May 13 17:23:47 vpn charon: 01[KNL] listening on interfaces:
May 13 17:23:47 vpn charon: 01[KNL] eth0
May 13 17:23:47 vpn charon: 01[KNL] 217.27.211.17
May 13 17:23:48 vpn charon: 01[KNL] fe80::20c:29ff:feb0:67dd
May 13 17:23:48 vpn charon: 01[KNL] eth1
May 13 17:23:48 vpn charon: 01[KNL] 192.168.129.180
May 13 17:23:48 vpn charon: 01[KNL] fe80::20c:29ff:feb0:67e7
May 13 17:23:48 vpn charon: 01[JOB] spawning 16 worker threads
May 13 17:23:48 vpn charon: 07[CFG] received stroke: add connection
'tunnelipsec'
May 13 17:23:48 vpn charon: 07[CFG] added configuration 'tunnelipsec':
217.27.211.17[217.27.211.17]...%any[%any]
May 13 17:24:31 vpn vpn: + 78.131.79.59 192.168.180.0/24 == 78.131.79.59
-- 217.27.211.17 == 192.168.129.0/24
r...@vpn:~# ipsec statusall
000 interface lo/lo ::1:500
000 interface lo/lo 127.0.0.1:4500
000 interface lo/lo 127.0.0.1:500
000 interface eth0/eth0 217.27.211.17:4500
000 interface eth0/eth0 217.27.211.17:500
000 interface eth1/eth1 192.168.129.180:4500
000 interface eth1/eth1 192.168.129.180:500
000 %myid = (none)
000 debug control
000
000 tunnelipsec:
192.168.129.0/24===217.27.211.17---217.27.211.62...%any==={192.168.0.0/16};
unrouted; eroute owner: #0
000 tunnelipsec: ike_life: 10800s; ipsec_life: 3600s; rekey_margin:
540s; rekey_fuzz: 100%; keyingtries: 3
000 tunnelipsec: policy: PSK+ENCRYPT+TUNNEL; prio: 24,16; interface:
eth0;
000 tunnelipsec: newest ISAKMP SA: #0; newest IPsec SA: #0;
000 tunnelipsec: IKE algorithms wanted: 7_128-2-14,
000 tunnelipsec: IKE algorithms found: 7_128-2_160-14,
000 tunnelipsec: ESP algorithms wanted: 3_000-1,
000 tunnelipsec: ESP algorithms loaded: 3_192-1_128,
000
Re: [strongSwan] how to create a ACL-like system based on certificates?
On Thu, 2010-05-13 at 01:02 +0200, Andreas Schuldei wrote: In order to have fine grained control over the IPsec traffic in our distributed network of host-to-host ipsec connections we would like to create a ACLs-like system. For example all servers should be able to talk to infrastructure hosts (like DNS or backup servers). Only the other storage servers and the few specialized servers accessing the storage system should be able to initiate connections to storage servers. Only the server distributing the search index and the few servers quering the search system should be able to initiate connections to search servers. The monitoring servers should be able to initiate connections to all servers. How could i represent such a system with different types of server certificates (one type per server class) and strongswan configuration? I'll toss my two cents in as I see no one else has responded yet. We've never done this at the IPSec level. We have done something similar by combining either IPSec or OpenVPN and iptables via the ISCS project (http://iscs.sourceforge.net). I've not had the time to build a community around ISCS so it is not as well maintained as I would like but it does give exactly this kind of control and that control can be based upon X.509 fields and those credentials can be used throughout the entire WAN without resorting to virtual IP addresses for security (although sometimes they are handy for routing and troubleshooting issues). There are several important fixes in the CVS awaiting to be rolled into a new release - John ___ Users mailing list Users@lists.strongswan.org https://lists.strongswan.org/mailman/listinfo/users
