Bug #199
left|rightsubnet =0.0.0.0/[1..30] will be parsed as 0.0.0.0/0
| Status: | Closed | Start date: | 30.06.2012 | |
|---|---|---|---|---|
| Priority: | Normal | Due date: | ||
| Assignee: | Martin Willi | % Done: | 0% | |
| Category: | libstrongswan | |||
| Target version: | 5.0.1 | |||
| 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 11 months ago
- Target version deleted (
5.0.0)
#2 Updated by Martin Willi 11 months 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.