On 5/27/19 10:23 AM, Jack Craig wrote: > so, i have enp420 & tun0. when tun0 comes up, route are not properly update for tun0 > routing. i think... > > default via 10.0.0.1 dev enp4s0 proto dhcp metric 100 > 10.0.0.0/24 <http://10.0.0.0/24> via 10.0.0.1 dev enp4s0 proto static metric 2 > 10.0.0.0/24 <http://10.0.0.0/24> dev enp4s0 proto kernel scope link src 10.0.0.101 > metric 100 > 10.8.0.0/24 <http://10.8.0.0/24> dev tun0 proto kernel scope link src 10.8.0.1 > 10.8.1.0/24 <http://10.8.1.0/24> via 10.8.0.2 dev tun0 > 10.8.2.0/24 <http://10.8.2.0/24> via 10.8.0.2 dev tun0 > 192.168.122.0/24 <http://192.168.122.0/24> dev virbr0 proto kernel scope link src > 192.168.122.1 linkdown > > looks like maybe some NM policy is broke? > > does NM create proper route for your vpn on NM restart? > > Before the vpn is started... [egreshko@meimei ~]$ ip -4 route show default via 192.168.1.1 dev enp2s0 proto static metric 100 192.168.1.0/24 dev enp2s0 proto kernel scope link src 192.168.1.18 metric 100 [root@meimei ~]# tcptraceroute 151.101.129.67 Running: traceroute -T -O info 151.101.129.67 traceroute to 151.101.129.67 (151.101.129.67), 30 hops max, 60 byte packets 1 wifi.greshko.com (192.168.1.1) 0.607 ms 0.546 ms 2.658 ms 2 211-75-128-254.HINET-IP.hinet.net (211.75.128.254) 6.886 ms 6.919 ms 6.897 ms 3 tpdt-3308.hinet.net (168.95.211.46) 7.212 ms 6.867 ms 7.150 ms 4 tpdt-3022.hinet.net (220.128.27.94) 7.819 ms 220-128-1-102.HINET-IP.hinet.net (220.128.1.102) 7.338 ms 7.760 ms 5 r4103-s2.tp.hinet.net (220.128.2.109) 7.224 ms r4103-s2.tp.hinet.net (220.128.2.13) 7.022 ms 7.020 ms 6 r4003-s2.tp.hinet.net (220.128.3.249) 7.036 ms 6.781 ms r4003-s2.tp.hinet.net (220.128.3.145) 19.583 ms 7 211-22-33-77.HINET-IP.hinet.net (211.22.33.77) 39.508 ms 39.141 ms 39.083 ms 8 HundredGE0-5-0-0.br02.hkg12.pccwbtn.net (63.218.174.197) 30.705 ms 31.085 ms 31.056 ms 9 HundredGE0-5-0-0.br02.hkg12.pccwbtn.net (63.218.174.197) 30.298 ms 30.503 ms 30.797 ms 10 fastly.bundle24.br02.hkg12.pccwbtn.net (63.217.237.106) 30.157 ms 30.205 ms 30.114 ms 11 151.101.129.67 (151.101.129.67) <syn,ack> 38.761 ms 36.893 ms 36.795 ms After the vpn is started... [egreshko@meimei ~]$ ip -4 route show default via 25.0.9.1 dev tun0 proto static metric 50 default via 192.168.1.1 dev enp2s0 proto static metric 100 25.0.9.0/24 dev tun0 proto kernel scope link src 25.0.9.5 metric 50 173.199.122.227 via 192.168.1.1 dev enp2s0 proto static metric 100 192.168.1.0/24 dev enp2s0 proto kernel scope link src 192.168.1.18 metric 100 192.168.1.1 dev enp2s0 proto static scope link metric 100 [root@meimei ~]# tcptraceroute 151.101.129.67 Running: traceroute -T -O info 151.101.129.67 traceroute to 151.101.129.67 (151.101.129.67), 30 hops max, 60 byte packets 1 _gateway (25.0.9.1) 208.511 ms 208.499 ms 208.497 ms 2 * * * 3 66.55.141.1 (66.55.141.1) 209.053 ms 209.060 ms 209.058 ms 4 * * * 5 * vl42-er1-q8.pnj1.choopa.net (108.61.2.90) 416.846 ms * 6 * * fastly-1.nyiix.net (198.32.160.22) 209.044 ms 7 151.101.129.67 (151.101.129.67) <syn,ack> 208.678 ms 208.799 ms fastly-1.nyiix.net (198.32.160.22) 209.042 ms I've not looked at the openVPN protocol in quite some time. However, if your configuration has the IPv4 configuration for the connection set to "Automatic" then isn't the server side responsible for sending routing information to the client? -- Right: I dislike the default color scheme Wrong: What idiot picked the default color scheme _______________________________________________ users mailing list -- users@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to users-leave@xxxxxxxxxxxxxxxxxxxxxxx Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/users@xxxxxxxxxxxxxxxxxxxxxxx
