Bug #199
left|rightsubnet =0.0.0.0/[1..30] will be parsed as 0.0.0.0/0
Start date:
30.06.2012
Due date:
Estimated time:
Affected version:
4.6.4
Resolution:
Description
The following ipsec.conf:
# ipsec.conf - strongSwan IPsec configuration file plutostart=no conn %default ikelifetime=60m keylife=20m rekeymargin=3m keyingtries=1 authby=secret keyexchange=ikev2 mobike=no conn net-net left=192.168.81.2 leftsubnet=0.0.0.0/1 # ---------^^^^^^^^^------ leftid=@t1.hs-mittweida.de leftfirewall=yes lefthostaccess=yes right=192.168.81.1 rightsubnet=141.55.81.0/24 rightid=@t2.hs-mittweida.de esp=aes128-md5! ike=aes128-sha1-modp3072! auto=add
reproduces the problem. Enterring "ipsec statusall" shows:
Status of IKE charon daemon (strongSwan 5.0.0rc1): uptime: 46 seconds, since Jun 30 04:21:58 2012 malloc: sbrk 405504, mmap 0, used 308544, free 96960 worker threads: 6 of 16 idle, 9/1/0/0 working, job queue: 0/0/0/0, scheduled: 0 loaded plugins: test-vectors curl ldap pkcs11 aes des sha1 sha2 md5 random nonce x509 revocation constraints pubkey ... Listening IP addresses: 192.168.81.2 Connections: net-net: 192.168.81.2...192.168.81.1 IKEv2 net-net: local: [t1.hs-mittweida.de] uses pre-shared key authentication net-net: remote: [t2.hs-mittweida.de] uses pre-shared key authentication net-net: child: 0.0.0.0/0 === 141.55.81.0/24 TUNNEL -----------^^^^^^^^^^^^------------------- Security Associations (0 up, 0 connecting): none
I have reproduced the problem with Strongswan 4.6.4 and 5.0.0rc1.
There is also a workaround: Use 0.0.0.1/1 instead. The host part of this address will be
masked out when narrowing down the subnet in ipsec.conf file.
Thanks
History
#1 Updated by Tobias Brunner about 10 years ago
- Target version deleted (
5.0.0)
#2 Updated by Martin Willi about 10 years ago
- Category changed from starter to libstrongswan
- Status changed from New to Closed
- Assignee set to Martin Willi
- Target version set to 5.0.1
It seems that we have enforced /0 for 0.0.0.0 subnets, probably to catch some problematic definitions for our recently replaced IP range calculation code. Doesn't make much sense now, fixed with 997fdd1f.
Thanks for reporting the issue, feel free to reopen if the problem persists.