Bug 10923 - OpenVPN N2N: openvpn subnet always uses class c networks
Summary: OpenVPN N2N: openvpn subnet always uses class c networks
Status: ASSIGNED
Alias: None
Product: IPFire
Classification: Unclassified
Component: --- (show other bugs)
Version: 2
Hardware: all All
: Will affect an average number of users Minor Usability
Assignee: Erik Kapfer
QA Contact:
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2015-09-12 17:05 UTC by Timo Eissler
Modified: 2020-03-28 09:39 UTC (History)
5 users (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Timo Eissler 2015-09-12 17:05:32 UTC
Look at the configuration of tun1 and tun2.

[root@ipfire1 ovpn]# ip addr show 
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN  
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00 
    inet 127.0.0.1/8 scope host lo 
       valid_lft forever preferred_lft forever 
3: red0: <BROADCAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP qlen 1000 
    link/ether 00:c0:08:8a:a0:4c brd ff:ff:ff:ff:ff:ff 
    inet 192.168.99.177/24 brd 192.168.99.255 scope global red0 
       valid_lft forever preferred_lft forever 
4: blue0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc fq_codel state DOWN qlen 1000 
    link/ether bc:30:7d:58:6c:86 brd ff:ff:ff:ff:ff:ff 
    inet 192.168.26.1/24 brd 192.168.26.255 scope global blue0 
       valid_lft forever preferred_lft forever 
5: green0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP  
    link/ether 00:c0:08:8a:a0:4b brd ff:ff:ff:ff:ff:ff 
    inet 192.168.25.1/24 brd 192.168.25.255 scope global green0 
       valid_lft forever preferred_lft forever 
8: tun0: <POINTOPOINT,MULTICAST,NOARP,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UNKNOWN qlen 100 
    link/none  
    inet 10.125.0.1 peer 10.125.0.2/32 scope global tun0 
       valid_lft forever preferred_lft forever 
9: tun1: <POINTOPOINT,MULTICAST,NOARP,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UNKNOWN qlen 100 
    link/none  
    inet 10.249.25.1 peer 10.249.25.2/32 scope global tun1 
       valid_lft forever preferred_lft forever 
10: tun2: <POINTOPOINT,MULTICAST,NOARP,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UNKNOWN qlen 100 
    link/none  
    inet 10.249.25.1 peer 10.249.25.2/32 scope global tun2 
       valid_lft forever preferred_lft forever 
[root@ipfire1 ovpn]# ip route show 
default via 192.168.99.1 dev red0  metric 203  
10.125.0.0/24 via 10.125.0.2 dev tun0  
10.125.0.2 dev tun0  proto kernel  scope link  src 10.125.0.1  
10.249.25.2 dev tun1  proto kernel  scope link  src 10.249.25.1  
10.249.25.2 dev tun2  proto kernel  scope link  src 10.249.25.1  
192.168.25.0/24 dev green0  proto kernel  scope link  src 192.168.25.1  
192.168.26.0/24 dev blue0  proto kernel  scope link  src 192.168.26.1  
192.168.27.0/24 via 10.249.25.2 dev tun1  
192.168.99.0/24 via 10.249.25.2 dev tun1  
192.168.99.0/24 dev red0  proto kernel  scope link  src 192.168.99.177  metric 203
Comment 1 Peter Müller 2018-04-26 17:56:29 UTC
This problem can be reproduced here.
Comment 2 Michael Tremer 2018-04-26 19:25:11 UTC
*what* is the problem?
Comment 3 Peter Müller 2018-04-26 19:29:42 UTC
The problem is that OpenVPN subnets (applies for both N2N and RW dial-in) are always used as /16 networks. To give an example, if I specify 10.99.101.0/24 as a OpenVPN network, it is not possible to create networks in 10.99.0.0/16 anymore ("network is already used by...").

This means that even only a /24 is specified, OpenVPN (or something related here) uses a /16 internally - which causes some problems, such as that one above.
Comment 4 Michael Tremer 2018-04-30 21:35:27 UTC
I still don't get it. Where is the /16 in the console output?
Comment 5 Michael Tremer 2018-06-18 14:27:15 UTC
I assume this isn't a bug any more. Please reopen in case you want this to be resolved.
Comment 6 Ano Nymous 2020-03-24 08:12:38 UTC
I think the bug is still open. I'll try to give an easy explaination:

Steps to reproduce

- Add OpenVPN Subnet with a /30 Network 10.0.0.4/255.255.255.252
- The ifconfig parameter in the n2nconf is 10.0.0.1 10.0.0.2

Expected

ifconfig parameter in the n2nconf 10.0.0.3 10.0.0.4
Comment 7 Michael Tremer 2020-03-24 11:31:55 UTC
Erik, are you up for another one?
Comment 8 Erik Kapfer 2020-03-28 09:39:33 UTC
Hi all,

(In reply to Michael Tremer from comment #7)
> Erik, are you up for another one?

as a first step --> https://git.ipfire.org/?p=people/ummeegge/ipfire-2.x.git;a=commit;h=1edbec992e1bbf77932ce6fcd147a3522020d1dd .
Open questions/work are in the commit message.

Help might be nice.

Best,

Erik