Modify

Opened 2 years ago

Last modified 12 months ago

#20729 new defect

proto 'none' overwriting tun interfaces

Reported by: openwrt@… Owned by: developers
Priority: normal Milestone:
Component: base system Version: Chaos Calmer 15.05
Keywords: Cc:

Description

I've been compiling OpenWRT builds for my home router (Netgear WNDR3800 and now a WD MyNet N750) for a number of years. I just recently encountered a problem with the OpenVPN tun interfaces are showing up without IP addresses after a reboot. I have the following in my /etc/config/network:

config interface 'vpn_udp'

option ifname 'tun0'
option proto 'none'

config interface 'vpn_tcp'

option ifname 'tun1'
option proto 'none'

Then, my /etc/openvpn/udp.ovpn and /etc/openvpn/tcp.ovpn reference "dev tun0" and "dev tun1", respectively. I do it this way so I can link "vpn_udp" and "vpn_tcp" into /etc/config/firewall, and other places, like I would any other network interface. What I expect is that the tun0 and tun1 interfaces look like this after a reboot:

tun0 Link encap:UNSPEC HWaddr 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00

inet addr:10.28.10.1 P-t-P:10.28.10.1 Mask:255.255.255.0
UP POINTOPOINT RUNNING NOARP MULTICAST MTU:1500 Metric:1
RX packets:0 errors:0 dropped:0 overruns:0 frame:0
TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:100
RX bytes:0 (0.0 B) TX bytes:0 (0.0 B)

tun1 Link encap:UNSPEC HWaddr 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00

inet addr:10.28.11.1 P-t-P:10.28.11.1 Mask:255.255.255.0
UP POINTOPOINT RUNNING NOARP MULTICAST MTU:1500 Metric:1
RX packets:253526 errors:0 dropped:0 overruns:0 frame:0
TX packets:356519 errors:0 dropped:834 overruns:0 carrier:0
collisions:0 txqueuelen:100
RX bytes:16948392 (16.1 MiB) TX bytes:451900041 (430.9 MiB)

However the interfaces look like this instead:

tun0 Link encap:UNSPEC HWaddr 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00

UP POINTOPOINT RUNNING NOARP MULTICAST MTU:1500 Metric:1
RX packets:0 errors:0 dropped:0 overruns:0 frame:0
TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:100
RX bytes:0 (0.0 B) TX bytes:0 (0.0 B)

tun1 Link encap:UNSPEC HWaddr 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00

UP POINTOPOINT RUNNING NOARP MULTICAST MTU:1500 Metric:1
RX packets:0 errors:0 dropped:0 overruns:0 frame:0
TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:100
RX bytes:0 (0.0 B) TX bytes:0 (0.0 B)

Note, the IP addresses are missing. Hence, even though the openvpn processes are running, traffic won't flow because the tun interfaces have had their IP addresses wiped. I have to manually run "/etc/init.d/openvpn restart" to get everything back to normal after reboot.

Am I missing something? This is happening on freshly compiled images from both the latest trunk and latest 15.05.

Attachments (0)

Change History (12)

comment:1 Changed 2 years ago by anonymous

And why none and not static? My config is

config interface 'vpn1'

option proto 'static'
option ifname 'tun0'
option auto '0'

config interface 'vpn2'

option proto 'static'
option ifname 'tun1'
option auto '0'

comment:2 Changed 2 years ago by anonymous

Specifying static would imply that I also want /etc/config/network to attach an IP address to the interface, which I don't want. OpenVPN will apply an address itself, /etc/config/network need not know anything about it.

comment:3 Changed 2 years ago by anonymous

Then why is mine working then and yours not? (: Static+auto=0 does the job, no ip at all at boot, and just ip by openvpn via script command at run time, and no ip again if tun device is gone.

comment:4 Changed 2 years ago by anonymous

Indeed, this change breaks existing setups ...

comment:5 Changed 2 years ago by anonymous

nothing broken, works fine for me.

comment:6 Changed 2 years ago by yousong

I also uses option proto none for tun interface configured by OpenVPN. The interface's IP address was indeed wiped out after a /e/i/network restart while the OpenVPN process kept running and wasn't aware of this and I had to do a /e/i/openvpn restart to again bring it up.

This is on OpenWrt CC release and I am not sure how did it work previously but I am not expecting this behaviour from netifd with proto none.

Last edited 2 years ago by yousong (previous) (diff)

comment:7 Changed 2 years ago by risa2000

I would like to add another take on this issue. As the OP I have been using option proto none for my tun0 in /etc/config/network. This has been working for years (e.g. in r45715).

Now, on the build from the trunk (r47874), I am getting exactly same behavior, although I am using ip instead of ifconfig. So after boot what I see is:

root@risa-wrt:~# ip addr
5: tun0: <POINTOPOINT,MULTICAST,NOARP,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UNKNOWN group default qlen 100
    link/none 

While the /tmp/openvpn.log from the startup shows that the addresses were correctly attached:

root@risa-wrt:~# cat /tmp/openvpn.log 
Sat Dec 12 14:03:19 2015 us=935399 OpenVPN 2.3.7 mips-openwrt-linux-gnu [SSL (PolarSSL)] [LZO] [EPOLL] [MH] [IPv6]
Sat Dec 12 14:03:19 2015 us=935639 library versions: PolarSSL 1.3.15, LZO 2.08
Sat Dec 12 14:03:19 2015 us=936670 Diffie-Hellman initialized with 1024 bit key
Sat Dec 12 14:03:19 2015 us=993689 WARNING: file '/etc/openvpn/risa-wrt.key' is group or others accessible
Sat Dec 12 14:03:20 2015 us=5046 crypto_adjust_frame_parameters: Adjusting frame parameters for crypto by 40 bytes
Sat Dec 12 14:03:20 2015 us=5358 TLS-Auth MTU parms [ L:1541 D:138 EF:38 EB:0 ET:0 EL:3 ]
Sat Dec 12 14:03:20 2015 us=5640 Socket Buffers: R=[163840->131072] S=[163840->131072]
Sat Dec 12 14:03:20 2015 us=33935 TUN/TAP device tun0 opened
Sat Dec 12 14:03:20 2015 us=34242 TUN/TAP TX queue length set to 100
Sat Dec 12 14:03:20 2015 us=34515 do_ifconfig, tt->ipv6=0, tt->did_ifconfig_ipv6_setup=0
Sat Dec 12 14:03:20 2015 us=34859 /sbin/ip link set dev tun0 up mtu 1500
Sat Dec 12 14:03:20 2015 us=41064 /sbin/ip addr add dev tun0 local 192.168.100.1 peer 192.168.100.2
Sat Dec 12 14:03:20 2015 us=49949 /sbin/ip route add 192.168.4.0/24 via 192.168.100.2
Sat Dec 12 14:03:20 2015 us=57522 /sbin/ip route add 192.168.100.0/24 via 192.168.100.2
Sat Dec 12 14:03:20 2015 us=66189 Data Channel MTU parms [ L:1541 D:1450 EF:41 EB:12 ET:0 EL:3 ]
Sat Dec 12 14:03:20 2015 us=66495 UDPv4 link local (bound): [undef]
Sat Dec 12 14:03:20 2015 us=66729 UDPv4 link remote: [undef]
Sat Dec 12 14:03:20 2015 us=66969 MULTI: multi_init called, r=256 v=256
Sat Dec 12 14:03:20 2015 us=67303 IFCONFIG POOL: base=192.168.100.4 size=62, ipv6=0
Sat Dec 12 14:03:20 2015 us=67565 IFCONFIG POOL LIST
Sat Dec 12 14:03:20 2015 us=68051 Initialization Sequence Completed
Sat Dec 12 14:03:22 2015 us=987040  event_wait returned 1
Sat Dec 12 14:03:22 2015 us=987747 UDPv4 read returned 53

Which confirms the OP's observration that they are probably attached, but lost afterwards.

I guess proto none was something like do not touch, which seems to be no longer the case.
Is the suggested static + auto=0 the right way to do it now, or was something broken in proto none handling?

comment:8 Changed 2 years ago by risa2000

I went ahead and changed my /etc/config/network to:

config interface        vpn
        option ifname   tun0
        option proto    static
        option auto     0

but I see the same behavior as described above. No IP address assigned on tun0 interface:

root@risa-wrt:~# ip addr
5: tun0: <POINTOPOINT,MULTICAST,NOARP> mtu 1500 qdisc fq_codel state DOWN group default qlen 100
    link/none

even though openvpn believes it did a correct job:

root@risa-wrt:~# cat /tmp/openvpn.log 
Sun Dec 13 11:10:35 2015 us=479025 OpenVPN 2.3.7 mips-openwrt-linux-gnu [SSL (PolarSSL)] [LZO] [EPOLL] [MH] [IPv6]
Sun Dec 13 11:10:35 2015 us=479271 library versions: PolarSSL 1.3.15, LZO 2.08
Sun Dec 13 11:10:35 2015 us=480290 Diffie-Hellman initialized with 1024 bit key
Sun Dec 13 11:10:35 2015 us=689545 WARNING: file '/etc/openvpn/risa-wrt.key' is group or others accessible
Sun Dec 13 11:10:35 2015 us=691493 crypto_adjust_frame_parameters: Adjusting frame parameters for crypto by 40 bytes
Sun Dec 13 11:10:35 2015 us=691798 TLS-Auth MTU parms [ L:1541 D:138 EF:38 EB:0 ET:0 EL:3 ]
Sun Dec 13 11:10:35 2015 us=692076 Socket Buffers: R=[163840->131072] S=[163840->131072]
Sun Dec 13 11:10:35 2015 us=721492 TUN/TAP device tun0 opened
Sun Dec 13 11:10:35 2015 us=721803 TUN/TAP TX queue length set to 100
Sun Dec 13 11:10:35 2015 us=722078 do_ifconfig, tt->ipv6=0, tt->did_ifconfig_ipv6_setup=0
Sun Dec 13 11:10:35 2015 us=722420 /sbin/ip link set dev tun0 up mtu 1500
Sun Dec 13 11:10:35 2015 us=730891 /sbin/ip addr add dev tun0 local 192.168.100.1 peer 192.168.100.2
Sun Dec 13 11:10:35 2015 us=749310 /sbin/ip route add 192.168.4.0/24 via 192.168.100.2
Sun Dec 13 11:10:35 2015 us=759795 /sbin/ip route add 192.168.100.0/24 via 192.168.100.2
Sun Dec 13 11:10:35 2015 us=778875 Data Channel MTU parms [ L:1541 D:1450 EF:41 EB:12 ET:0 EL:3 ]
Sun Dec 13 11:10:35 2015 us=779184 UDPv4 link local (bound): [undef]
Sun Dec 13 11:10:35 2015 us=779417 UDPv4 link remote: [undef]
Sun Dec 13 11:10:35 2015 us=779656 MULTI: multi_init called, r=256 v=256
Sun Dec 13 11:10:35 2015 us=780002 IFCONFIG POOL: base=192.168.100.4 size=62, ipv6=0
Sun Dec 13 11:10:35 2015 us=780262 IFCONFIG POOL LIST
Sun Dec 13 11:10:35 2015 us=780734 Initialization Sequence Completed
Sun Dec 13 11:10:45 2015 us=785311  event_wait returned 0
Sun Dec 13 11:10:46 2015 us=281405  event_wait returned 1

The only difference compared to the original configuration with proto none is the state of tun0 interface after the boot (it is DOWN).

I am on r47874.

comment:9 follow-up: Changed 2 years ago by risa2000

I still have this problem on the latest build r48934 DESIGNATED DRIVER (Bleeding Edge, r48934). Neither proto none nor proto static + auto 0 does work for me.

The IP address is destroyed possibly by netifd, just when openvpn is already running and the only way to correct it is etc/init.d/openvpn restart.

comment:10 in reply to: ↑ 9 ; follow-up: Changed 2 years ago by xavier@…

Replying to risa2000:

I still have this problem on the latest build r48934 DESIGNATED DRIVER (Bleeding Edge, r48934). Neither proto none nor proto static + auto 0 does work for me.

The IP address is destroyed possibly by netifd, just when openvpn is already running and the only way to correct it is etc/init.d/openvpn restart.

have you tried using the option enabled '0' option, which disables or enables the interface section that should prolly keep netifd from touching/interfering with said interface?

comment:11 in reply to: ↑ 10 Changed 18 months ago by risa2000

Replying to xavier@…:

have you tried using the option enabled '0' option, which disables or enables the interface section that should prolly keep netifd from touching/interfering with said interface?

Actually, I have just run the test on r49395, using option enabled '0' and noticed that while netifd is no longer involved (according to the system log) with vpn interface setup, I still do not get the correct configuration on this interface once the system fully starts.

After looking into system log I noticed that openvpn starts earlier than network. Which is strange since network has S20network and openvpn has S90openvpn.

What is also strange S65ntpd starts also before everything else.

I guess the problem lies in the fact that openvpn starts before the network is initialized. Right now however, I do not know, why it happens and if it is intended.

comment:12 Changed 12 months ago by grumbler_eburg

It is need to don't define any interface with the ifname "tunX" and "tapX". These interfaces served by OpenVPN and netifd should not tell its.

Simple remove these lines from the file /etc/config/network:

config interface        vpn
        option ifname   tun0
        option proto    static
        option auto     0
config interface 'vpn1'

    option proto 'static'
    option ifname 'tun0'
    option auto '0'
config interface 'vpn2'

    option proto 'static'
    option ifname 'tun1'
    option auto '0'
Last edited 12 months ago by grumbler_eburg (previous) (diff)

Add Comment

Modify Ticket

Action
as new .
Author


E-mail address and user name can be saved in the Preferences.

 
Note: See TracTickets for help on using tickets.