search

stangri / source.openwrt.melmac.net

OpenWrt Packages
GNU General Public License v3.0
147 stars 45 forks source link

[bug report] VPN routing not working after router (re)boot #7

Closed ghost closed 6 years ago

ghost commented 6 years ago

Router Turri Omnia OpenWrt omnia 15.05 r47055 / LuCI cc8b99aacec15490bb725fe53abefa1156cb5fe3 branch (git-18.123.42193-cc8b99a) Kernel 4.4.131-a2dbf3bef3d0c1f725e0a5f0801935a1-2

PBR is starting prior the ovpn tun is up during router boot and thus fails to create a routing table for the tun

notice [2569]: Creating table 'wan/pppoe-wan/ip.redacted' [✓] notice openvpn[2546]: TCP/UDP: Preserving recently used remote address: [AF_INET]ip.redacted:61023 notice openvpn[2546]: UDPv4 link local (bound): [AF_INET]192.168.112.12:61023 notice openvpn[2546]: UDPv4 link remote: [AF_INET]ip.redacted:61023 notice openvpn[2546]: VERIFY OK: depth=2, notice openvpn[2546]: VERIFY OK: depth=1, notice openvpn[2546]: VERIFY KU OK notice openvpn[2546]: Validating certificate extended key usage notice openvpn[2546]: ++ Certificate has EKU (str) TLS Web Server Authentication, expects TLS Web Server Authentication notice openvpn[2546]: VERIFY EKU OK notice openvpn[2546]: VERIFY OK: depth=0, notice openvpn[2546]: peer info: IV_VER=2.4.4 notice openvpn[2546]: peer info: IV_PLAT=linux notice openvpn[2546]: peer info: IV_PROTO=2 notice openvpn[2546]: peer info: IV_LZ4=1 notice openvpn[2546]: peer info: IV_LZ4v2=1 notice openvpn[2546]: peer info: IV_LZO=1 notice openvpn[2546]: peer info: IV_COMP_STUB=1 notice openvpn[2546]: peer info: IV_COMP_STUBv2=1 notice openvpn[2546]: peer info: IV_TCPNL=1 notice openvpn[2546]: peer info: IV_SSL=OpenSSL_1.0.2l__25_May_2017 notice openvpn[2546]: Control Channel: TLSv1.2, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-GCM-SHA384, 4096 bit RSA 2018-05-11 22:49:00 notice openvpn[2546]: [CA OVPN Server] Peer Connection Initiated with [AFINET]ip.redacted:61023 notice [2569]: Creating table 'ovpn/tun0/0.0.0.0' [✗] notice [2569]: Routing 's5' via wan [✓] notice [2569]: Routing 's1' via wan [✓] notice [2569]: Routing 'da' via wan [✓] notice [2569]: Routing '1750e' via wan [✓] notice [2569]: Routing 'dvb-c' via wan [✓] notice [2569]: Routing 'stv9s' via wan [✓] notice [2569]: Routing 'lan' via wan [✓] notice [2569]: service started on wan/pppoe-wan/ip.redacted with errors [✗] notice [2569]: ERROR: Failed to set up 'ovpn/tun0/0.0.0.0'_ notice openvpn[2546]: Data Channel: using negotiated cipher 'AES-256-GCM' notice openvpn[2546]: Outgoing Data Channel: Cipher 'AES-256-GCM' initialized with 256 bit key notice openvpn[2546]: Incoming Data Channel: Cipher 'AES-256-GCM' initialized with 256 bit key notice openvpn[2546]: TUN/TAP device tun0 opened notice openvpn[2546]: do_ifconfig, tt->did_ifconfig_ipv6_setup=0 notice openvpn[2546]: /sbin/ifconfig tun0 172.24.120.2 netmask 255.255.255.0 mtu 1500 broadcast 172.24.120.255 notice netifd[]: Interface 'ovpn' is enabled notice netifd[]: Network device 'tun0' link is up notice netifd[]: Interface 'ovpn' has link connectivity notice netifd[]: Interface 'ovpn' is setting up now notice netifd[]: Interface 'ovpn' is now up notice openvpn[2546]: UID set to nobody notice openvpn[2546]: Initialization Sequence Completed

stangri commented 6 years ago

VPR should be automatically reloaded if any of the supported interfaces go up. Watch for the line in log stating something like: 20:15:01 vpn-policy-routing [3446]: service monitoring interfaces: wan vpnc

ghost commented 6 years ago

It does indeed whenever an iface change happens but unfortunately not during or right after the boot sequence. To get started after a reboot it requires a manual PBR reload, either through the cli or LuCI.

It was reported by another user at the TO forum and reproduced this end.

p4p4-GitHub commented 6 years ago

I have the same issue like n8v8R with a Turris Omnia. I have to save&apply changes in the PBR settings menu after reboot, then it works.

OpenWrt omnia 15.05 r47055 Kernel Version | 4.4.131-a2dbf3bef3d0c1f725e0a5f0801935a1-2

ghost commented 6 years ago

Just speculating after reading https://forum.turris.cz/t/vpn-policy-based-routing-possible/7204/32

e.g. logread is not functional, they use syslog-ng which writes to /var/log/messages

Is VPBR (service monitoring interfaces) relying on logread and thus perhaps the root cause?

And would logging (Open)VPN to another/separate file other than the syslog (/var/log/messages) , e.g. option log '/tmp/log/openvpn.log' in “/etc/config/openvpn” impede VPBR's monitoring capability? If so could this be remedied with an option in VPBR to point such (Open)VPN log file?

ghost commented 6 years ago

referencing https://forum.turris.cz/t/vpn-policy-based-routing-possible/7204/40