Project

General

Profile

Bug #199

left|rightsubnet =0.0.0.0/[1..30] will be parsed as 0.0.0.0/0

Added by Juergen Seifert about 13 years ago. Updated about 13 years ago.

Status:
Closed
Priority:
Normal
Assignee:
Martin Willi
Category:
libstrongswan
Target version:
5.0.1
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 13 years ago

  • Target version deleted (5.0.0)

#2 Updated by Martin Willi about 13 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 commit:997fdd1f.

Thanks for reporting the issue, feel free to reopen if the problem persists.