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 over 8 years ago. Updated over 8 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 over 8 years ago

  • Target version deleted (5.0.0)

#2 Updated by Martin Willi over 8 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.

Also available in: Atom PDF