Bug 10923

Summary:	OpenVPN N2N: openvpn subnet always uses class c networks
Product:	IPFire	Reporter:	Timo Eissler <morlix>
Component:	---	Assignee:	Erik Kapfer <ummeegge>
Status:	ASSIGNED ---	QA Contact:
Severity:	Minor Usability
Priority:	Will affect an average number of users	CC:	ipfire, michael.tremer, morlix, peter.mueller, ummeegge
Version:	2
Hardware:	all
OS:	All
See Also:	https://bugzilla.ipfire.org/show_bug.cgi?id=11131

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