[solved] - Questions about Open VPN Client

Wir haben aktuell ein Problem mit dem Board und arbeiten an der Lösung...


-> Aktuell bereiten wir das Upgrade auf die aktuelle Version 6 von Woltlab vor.

    Thanks Andre
    Do I need to download and install BusyBox package? In dreamboxupdate.com, 8 BusyBox packages found. Which should I install?

    Code
    busybox-dbg_1.19.4-r8-dream13_mips32el.ipk
busybox-dev_1.19.4-r8-dream13_mips32el.ipk
busybox-syslog-systemd_1.19.4-r8-dream13_mips32el.ipk
busybox-syslog_1.19.4-r8-dream13_mips32el.ipk
busybox-systemd_1.19.4-r8-dream13_mips32el.ipk
busybox-udhcpc_1.19.4-r8-dream13_mips32el.ipk
busybox-xinetd_1.19.4-r8-dream13_mips32el.ipk
busybox_1.19.4-r8-dream13_mips32el.ipk


    The output of route-n command and the ip route, before starting openvpn:


    The output of route-n command and the ip route, after starting openvpn:


    The output of the command:

    Code
    root@dm500hd:~# route add -net 141.255.161.118 netmask 255.255.255.255 gw 192.16
8.1.1
route: SIOCADDRT: File exists


    Code
    root@dm500hd:~# route add -host 141.255.161.118 gw 192.168.1.1
route: SIOCADDRT: File exists


    Code
    root@dm500hd:~# ip route add 141.255.161.118/32 via 192.168.1.1
ip: RTNETLINK answers: File exists


    New log file attached.


    Ping result:


    BUT:

    Code
    root@dm500hd:~# ping yahoo.com
ping: bad address 'yahoo.com'
root@dm500hd:~#


    Unfortunately, the problem remains!


    Best Regard
    Naser

    Quote

    Originally posted by n@ser
    Do I need to download and install BusyBox package? In dreamboxupdate.com, 8 BusyBox packages found. Which should I install?


    None of them, the error to install the host route was probably just due to the route already being in the table.


    Quote

    The output of route-n command and the ip route, before starting openvpn:


    Cool, that verifies your default gateway. It also shows that you experimented with another VPN peer which left a lingering host route in your RIB, which nicely explains why the next attempt to start the same VPN session will produce a harmless error message on trying to insert it a second time.


    Quote

    The output of route-n command and the ip route, after starting openvpn:


    Congratulations, your VPN is up and running. Believe it or not, from the IP routing point of view, you are golden. The host route to your peer as well as the two /1 routes via tun0 all made it to the RIB and you are 99% there.


    Quote

    The output of the command:

    Code
    root@dm500hd:~# route add -net 141.255.161.118 netmask 255.255.255.255 gw 192.16
8.1.1
route: SIOCADDRT: File exists


    Code
    root@dm500hd:~# route add -host 141.255.161.118 gw 192.168.1.1
route: SIOCADDRT: File exists


    Code
    root@dm500hd:~# ip route add 141.255.161.118/32 via 192.168.1.1
ip: RTNETLINK answers: File exists


    Nice, all three attempts would have worked (no issues with the relevant binaries), they just didn't have anything to do for the route already being active.


    Quote

    New log file attached.


    That log against 198.105.212.166 looks a little strange. You might be MITMed here, be vigilant. Trying to mix two different OpenVPN peers is also a recipe for disaster if not well coordinated, it may produce all kinds of new errors. Try to get the session against 141.255.161.118 working, that one looks good.


    Quote

    Ping result:


    You even reach http://www.google.com (working DNS name resolution!) and the Google DNS servers through your VPN.


    Quote

    BUT:

    Code
    root@dm500hd:~# ping yahoo.com
ping: bad address 'yahoo.com'
root@dm500hd:~#


    Unfortunately, the problem remains!


    Believe me, the problem that remains is a trivial flyspeck compared to what you already have achieved. You cannot resolve yahoo.com. But seconds before, you could resolve http://www.google.com. And you reach 8.8.8.8 so you could use Google DNS through your VPN.


    As a first measure to find out why your DNS behaves so strange, just give us the output of cat /etc/resolv.conf when the VPN is established and we will see what DNS you are trying to use. I somehow expect it to be 192.168.1.1 which is your router's DNS resolver. That resolver will still be affected by the censoring measures of your Internet access and this might prevent it from resolving anything but a whitelist of sites. If that is the case, try to use 8.8.8.8 as a name server when the VPN is established like that:

    Code
    root@dm7020hd:~# nslookup yahoo.com 8.8.8.8
Server:    8.8.8.8
Address 1: 8.8.8.8 google-public-dns-a.google.com


Name:      yahoo.com
Address 1: 98.139.183.24 ir2.fp.vip.bf1.yahoo.com
Address 2: 98.138.253.109 ir1.fp.vip.ne1.yahoo.com
Address 3: 206.190.36.45 ir1.fp.vip.gq1.yahoo.com


    If that works out, you should try to just configure 8.8.8.8 as your DNS. Ideally you would find one that works whether the VPN is established or not.


    Regarding DNS push, maybe it's just some lines missing from your client .ovpn file. I've never seen that actual GP package, but if it comes with a script called /etc/openvpn/update-resolv-conf it may suffice to add this to the client .ovpn file:

    Code
    script-security 2
up /etc/openvpn/update-resolv-conf
down /etc/openvpn/update-resolv-conf


    For rationale and potential different location of that script see also here.


    If that script is not there, it might work out simpler to come up with a minimal script that just pushes 8.8.8.8 to resolvconf and hook that into the .ovpn using the up/down statements.


    HTH,
    Andre.

    Thanks Andre
    You see, unfortunately, the Iranian government to censor the Internet.
    Sites like Google and Yahoo are open, but sites like Facebook,Twitter,DMM are blocked.
    But when the vpn is connect only have access to Google, other sites like Yahoo could not be opened! But when the VPN is disconnected, Yahoo opens well.


    When the connect Openvpn is:

    Code
    dm500hd login: root
root@dm500hd:~# cat /etc/resolv.conf
# Generated by resolvconf
nameserver 92.42.51.31
nameserver 92.42.51.77


    Code
    root@dm500hd:~# nslookup yahoo.com 8.8.8.8
Server:    8.8.8.8
Address 1: 8.8.8.8


nslookup: can't resolve 'yahoo.com'


    When ovpn is disconnected:


    I am using the CVS + Gp3.2 image.
    But I'm using a dumbo, dumbo is the problem?


    Thanks

    Quote

    Originally posted by n@ser
    Sites like Google and Yahoo are open, but sites like Facebook,Twitter,DMM are blocked.
    But when the vpn is connect only have access to Google, other sites like Yahoo could not be opened! But when the VPN is disconnected, Yahoo opens well.


    Argh, I just wrote a lengthy reply but my silly browser fragged it...
    Anyway, I'll try again:


    Quote

    When the connect Openvpn is:

    Code
    dm500hd login: root
root@dm500hd:~# cat /etc/resolv.conf
# Generated by resolvconf
nameserver 92.42.51.31
nameserver 92.42.51.77


    This tells us two things: You are using Iran Cell ISP DNS servers, and they are not overridden when you connect the OpenVPN session. This explains your problems - these servers will not answer when your queries are coming from an outside address like your VPN one. This is legitimate, DNS multiplication DDoS attacks have been all the rage lately and globally reachable recursive resolvers are on the decline as a result. You have to use something else like 8.8.8.8:

    Code
    root@dm500hd:~# nslookup yahoo.com 8.8.8.8
Server:    8.8.8.8
Address 1: 8.8.8.8


nslookup: can't resolve 'yahoo.com'


    Now that is strange! Sadly, I relied again on a lobotomized BusyBox version of a well known command, which in this case isn't just reduced to a mere shadow of itself, it's actually broken and lying blatantly. Look at this:

    Code
    root@dm7020hd:~# nslookup yahoo.com 8.8.8.8
Server:    8.8.8.8
Address 1: 8.8.8.8


nslookup: can't resolve 'yahoo.com'


    That happened after I changed the nameserver statement in my resolv.conf to something which isn't a DNS server. On the other hand, with a working resolv.conf, you can write any address there and it will pretend it got an answer from it - just try 1.2.3.4...


    So we cannot rely on BusyBox nslookup telling us the truth. This finally explains your result: nslookup is still just asking the Iran Cell DNS servers, and they still don't answer your VPN address.


    Quote

    When ovpn is disconnected:


    Now you're asking the same servers from a legitimate querier source address and get an answer. Sadly, given the nslookup breakage, this doesn't tell us if 8.8.8.8 is reachable for you without VPN...


    Quote

    I am using the CVS + Gp3.2 image.
    But I'm using a dumbo, dumbo is the problem?


    I don't expect it to be a problem here.


    Now try the following: Connect the VPN, then override your resolvers towards Google:

    Code
    echo "nameserver 8.8.8.8" > /etc/resolv.conf


    After that, you should be able to resolve names (ping yahoo.com and others). If that finally works, disconnect the VPN and see if you still can resolve names. I don't expect so, but if it still works, it makes things a lot easier for you - just change your resolver to 8.8.8.8 permanently. If it isn't working, you will probably have to go the up/down-script route in the client .ovpn config file.


    BTW, the above command overwrote your resolv.conf file. To get it back to the original state, the easiest way is probably to reboot your box. Any other way of getting the content you cited here twice back in there will of course work as well, without reboot. Dunno how versed you are in vi though :winking_face:


    HTH,
    Andre.

    I According to the wiki article, the steps I did.
    Fortunately openresolv package by default, is installed on the CVS image. Also available here: openresolv_3.5.2-r0_all.ipk


    I got a copy of the script path /etc/openvpn.
    With this recipe, I had to change the access level:

    Code
    chmod +x /etc/openvpn/update-resolv-conf


    I added these lines with client.ovpn:

    Code
    script-security 2
up /usr/share/openvpn/update-resolv-conf
down /usr/share/openvpn/update-resolv-conf


    I do not have this directory. Do I need to manually create?


    Unfortunately ovpn not connect! This error is recorded in the log:

    Code
    script failed: could not execute external program


    Logs attached.


    Regard

    Quote

    Originally posted by ABPSoft
    Now try the following: Connect the VPN, then override your resolvers towards Google:

    Code
    echo "nameserver 8.8.8.8" > /etc/resolv.conf


    After that, you should be able to resolve names (ping yahoo.com and others). If that finally works, disconnect the VPN and see if you still can resolve names. I don't expect so, but if it still works, it makes things a lot easier for you - just change your resolver to 8.8.8.8 permanently. If it isn't working, you will probably have to go the up/down-script route in the client .ovpn config file.


    Many thanks
    This recipe will work well. After pressing this recipe, I was able to ping all the sites.
    The problem was solved. Thank you very much. There's just one problem, I should each time would enter this command, otherwise the previous problem remains.
    Is there a solution to this problem?


    Regard

    • Official Post

    Ok - Great
    I mark the problem as "solved"


    THX to all


    Jake

    | 2 x 920 ULTRA HD | 2 x TWO | 7080 HD| 8000 HD | 7020 HD V2 | 800 HD SE V2 |
    |GP 4.2 & GP 3.2 & GP 3 @ DREAMOS & DMM-Experimental | on all Boxes
    | Hdd : | 2 x 4 TB :tired_face: 1 TB | Qnap - 8 TB |... and some more space everywhere
    WaveFrontier T 90 : | Hotbird 13 ° | Astra 19,2° | Astra 23,5° | Astra/Eurobird 28,2°/28,5° |
    ........... and happy :winking_face:


    Hier werden Sie geholfen : Gemini Project WIKI sowie Video Tutorials

    Chmod resolv.conf, I changed to 444. The problem was solved.
    Special thanks to all my friends. (Especially Andre and Jake.) :437: :danke:

    Quote

    Originally posted by n@ser
    Chmod resolv.conf, I changed to 444. The problem was solved.


    While that may work out, it's an ugly way to permanently change your resolver to 8.8.8.8. I assume your Dreambox is using DHCP to aquire IP address, gateway and DNS servers? If you have access to the DHCP server giving out the data (usually that is a service running on your Internet router), you may be able to just reconfigure it to always hand out 8.8.8.8 instead of the servers it gets from the ISP side. Another option would be to configure the Dreambox with a static IP including static DNS server. Or continue the external script route, coming up with a minimal script that uses resolvconf to change the nameserver to 8.8.8.8 on VPN up and back to the original on VPN down. There are quite a number of options to proceed from here and make this actually robust. They just need some time and experimenting.


    HTH,
    Andre.

    Thank you for your valuable advice.