Join GitHub today
GitHub is home to over 28 million developers working together to host and review code, manage projects, and build software together.
Sign upVPN script problem on Fedora: cannot resolve domain names #3348
Comments
This comment has been minimized.
Show comment
Hide comment
This comment has been minimized.
andrewdavidwong
Nov 30, 2017
Member
Based on our issue reporting guidelines, this does not appear to be suitable for qubes-issues. We ask that you please send this to the qubes-users mailing list instead. If, after reading our issue reporting guidelines, you believe we are mistaken, please leave a brief comment explaining why. We'll be happy to take another look, and, if appropriate, reopen this issue. Thank you for your understanding.
|
Based on our issue reporting guidelines, this does not appear to be suitable for |
andrewdavidwong
closed this
Nov 30, 2017
andrewdavidwong
added
the
invalid
label
Nov 30, 2017
This comment has been minimized.
Show comment
Hide comment
This comment has been minimized.
boistordu
Nov 30, 2017
I think it's indeed a problem with qubes and it's correlated to qubes guidelines.
I've followed : wiki and all the scripts in it. So it should workd as intended in the wiki pages.
Problem, it is not... The proxyvm is working as intended if I'm using the network manager.... So there is clearly a problem with one of the script and the new fedora.
boistordu
commented
Nov 30, 2017
|
I think it's indeed a problem with qubes and it's correlated to qubes guidelines. |
andrewdavidwong
reopened this
Dec 1, 2017
andrewdavidwong
added
bug
C: other
and removed
invalid
labels
Dec 1, 2017
andrewdavidwong
added this to the Release 3.2 updates milestone
Dec 1, 2017
andrewdavidwong
added
the
C: Fedora
label
Dec 1, 2017
andrewdavidwong
changed the title from
problem vpn VM
to
VPN script problem on Fedora: cannot resolve domain names
Dec 1, 2017
This comment has been minimized.
Show comment
Hide comment
This comment has been minimized.
|
Reopened and updated title to be more descriptive. |
This comment has been minimized.
Show comment
Hide comment
This comment has been minimized.
boistordu
Dec 2, 2017
no idea about what could be wrong with the script about the dns ? How should I debug this anyway? Don't know which log even to look for
boistordu
commented
Dec 2, 2017
|
no idea about what could be wrong with the script about the dns ? How should I debug this anyway? Don't know which log even to look for |
This comment has been minimized.
Show comment
Hide comment
This comment has been minimized.
|
@tasket might be the best person to ask about this. |
This comment has been minimized.
Show comment
Hide comment
This comment has been minimized.
tasket
Dec 3, 2017
@boistordu ping no longer works well under the user/group restriction, so its better to focus on the client software itself (i.e. openvpn) for diagnostics.
For logs, you can check journalctl for openvpn entries, or test openvpn directly as suggested in the vpn doc. One place where dns can fail is PR-QBS chain in iptables, so checking that for the correct addresses is a good idea.
I don't have an R3.2 system right now, but I can try out the fedora-26 template on R4-rc3 tonight to see if a dns problem occurs there.
tasket
commented
Dec 3, 2017
|
@boistordu For logs, you can check I don't have an R3.2 system right now, but I can try out the fedora-26 template on R4-rc3 tonight to see if a dns problem occurs there. |
This comment has been minimized.
Show comment
Hide comment
This comment has been minimized.
tasket
Dec 3, 2017
@marmarek It appears that in fedora-26-minimal parts of netfilter and qubes guest are missing or not configured and I'm not sure which packages are needed to bring the template up to spec; I looked in docs but didn't see a guide.
tasket
commented
Dec 3, 2017
|
@marmarek It appears that in fedora-26-minimal parts of netfilter and qubes guest are missing or not configured and I'm not sure which packages are needed to bring the template up to spec; I looked in docs but didn't see a guide. |
This comment has been minimized.
Show comment
Hide comment
This comment has been minimized.
boistordu
Dec 3, 2017
the openvpn was working before the implementation of the differents scripts that's for sure. Better proof is that with the same openvpn script I was connecting through network manager before on a different proxyvm.And anyway it's a big vpn company so it's a script that I would have done or something like that.
if ping doesn't work anymore it coud be a good idea to change the wiki page then to say that even with sg it doesn't work.
so what could be faulty here is maybe the lines added in openvpn script from the wiki page or the iptables script.
with journalctl I don't see any error besides the pulseaudio error. Should I have any error? Since it is a DNS problem, I would more likely look at the transfer of env variables from script to script than anything else.
boistordu
commented
Dec 3, 2017
|
the openvpn was working before the implementation of the differents scripts that's for sure. Better proof is that with the same openvpn script I was connecting through network manager before on a different proxyvm.And anyway it's a big vpn company so it's a script that I would have done or something like that. |
This comment has been minimized.
Show comment
Hide comment
This comment has been minimized.
boistordu
Dec 3, 2017
about the PR-QBS chain I don't see anything related to those lines in the script:
for addr in $vpn_dns; do
iptables -t nat -A PR-QBS -i vif+ -p udp --dport 53 -j DNAT --to $addr
iptables -t nat -A PR-QBS -i vif+ -p tcp --dport 53 -j DNAT --to $addr
So it's more likely that the $vpn_dns env var didn't go through.
there is only 4 lines in it in place of 6 with 2 that would be tcp dpt:53 related
boistordu
commented
Dec 3, 2017
|
about the PR-QBS chain I don't see anything related to those lines in the script: So it's more likely that the $vpn_dns env var didn't go through. |
This comment has been minimized.
Show comment
Hide comment
This comment has been minimized.
boistordu
Dec 3, 2017
but maybe it is my fault, because of this problem my understanding of the :
# To override DHCP DNS, assign DNS addresses to 'vpn_dns' env variable before calling this script;
# Format is 'X.X.X.X Y.Y.Y.Y [...]'
is different now. Do I need to put myself the dns addresses ? Because with network manager I didn't had to do that.... So I was thinking that it was automatically added because of the ovpn script?
boistordu
commented
Dec 3, 2017
|
but maybe it is my fault, because of this problem my understanding of the : is different now. Do I need to put myself the dns addresses ? Because with network manager I didn't had to do that.... So I was thinking that it was automatically added because of the ovpn script? |
This comment has been minimized.
Show comment
Hide comment
This comment has been minimized.
tasket
Dec 3, 2017
Override is not necessary if DHCP is working; normally DNS assignment is automatic.
The log should have a line like:
openvpn[1234]: Using DNS servers x.x.x.x y.y.y.y
with x and y being actual numbers. It should also have a line that says Initialization sequence completed.
However, I'll reiterate that I can't get fedora-26-minimal working properly... it does not seem ready for general use. At this point I'd suggest using a Debian 8 or 9 template instead.
tasket
commented
Dec 3, 2017
|
Override is not necessary if DHCP is working; normally DNS assignment is automatic. The log should have a line like: with x and y being actual numbers. It should also have a line that says However, I'll reiterate that I can't get fedora-26-minimal working properly... it does not seem ready for general use. At this point I'd suggest using a Debian 8 or 9 template instead. |
This comment has been minimized.
Show comment
Hide comment
This comment has been minimized.
boistordu
Dec 3, 2017
the log has nothing related to : sudo journalctl | grep "DNS servers"
but it does say "Initialization Sequence complete"
so can I use the same appvm but just change the template origin?
boistordu
commented
Dec 3, 2017
•
edited
Edited 1 time
-
boistordu
edited Dec 3, 2017 (most recent)
edited
-
Dec 3, 2017 (most recent)
|
the log has nothing related to : so can I use the same appvm but just change the template origin? |
This comment has been minimized.
Show comment
Hide comment
This comment has been minimized.
boistordu
Dec 3, 2017
same result with the debian 9 template. the vpn link is up but the dns requested are still no-go
boistordu
commented
Dec 3, 2017
|
same result with the debian 9 template. the vpn link is up but the dns requested are still no-go |
This comment has been minimized.
Show comment
Hide comment
This comment has been minimized.
boistordu
Dec 3, 2017
So can we just simply see together the different script ? and how does it work script by script?
boistordu
commented
Dec 3, 2017
|
So can we just simply see together the different script ? and how does it work script by script? |
This comment has been minimized.
Show comment
Hide comment
This comment has been minimized.
boistordu
Dec 3, 2017
Dec 03 23:07:42 VPN systemd[1]: Started OpenVPN service.
Dec 03 23:07:42 VPN systemd-resolved[670]: Positive Trust Anchors:
Dec 03 23:07:42 VPN systemd-resolved[670]: . IN DS 19036 8 2 somenumbers
Dec 03 23:07:42 VPN systemd-resolved[670]: . IN DS 20326 8 2 somenumbers
Dec 03 23:07:42 VPN systemd-resolved[670]: Negative trust anchors: 10.in-addr.arpa 16.172.in-addr.arpa 17.172.in-
Dec 03 23:07:42 VPN systemd-resolved[670]: Using system hostname 'VPN'.
Dec 03 23:07:42 VPN systemd-resolved[670]: Switching to system DNS server 10.137.2.1.
Dec 03 23:07:42 VPN dbus[529]: [system] Successfully activated service 'org.freedesktop.nm_dispatcher'
Dec 03 23:07:42 VPN systemd[1]: Started Network Manager Script Dispatcher Service.
Dec 03 23:07:42 VPN NetworkManager[575]: <info> [1512338862.5942] settings: loaded plugin keyfile: (c) 2007 - 20
Dec 03 23:07:42 VPN su[674]: Successful su for user by root
boistordu
commented
Dec 3, 2017
•
edited
Edited 1 time
-
boistordu
edited
Dec 3, 2017 (most recent)
edited
-
Dec 3, 2017 (most recent)
|
This comment has been minimized.
Show comment
Hide comment
This comment has been minimized.
boistordu
Dec 3, 2017
still the same 4 lines in the iptables.
no dns transaction at all in the journalctl.
maybe from the start it does not transfer any DNS.... Because when I was using the openvpn script in network manager, maybe it was the dns from my local network and not from the vpn provider
boistordu
commented
Dec 3, 2017
|
still the same 4 lines in the iptables. maybe from the start it does not transfer any DNS.... Because when I was using the openvpn script in network manager, maybe it was the dns from my local network and not from the vpn provider |
This comment has been minimized.
Show comment
Hide comment
This comment has been minimized.
boistordu
Dec 3, 2017
I just seen on the forum from the vpn provider, they send dns with the connection.
They had in the script to prevent the leak:
script-security 2
up /etc/openvpn/update-resolv-conf
down /etc/openvpn/update-resolv-conf
so is it interfering with this part?
script-security 2
up '/rw/config/vpn/qubes-vpn-handler.sh up'
down '/rw/config/vpn/qubes-vpn-handler.sh down'
boistordu
commented
Dec 3, 2017
|
I just seen on the forum from the vpn provider, they send dns with the connection. so is it interfering with this part? |
This comment has been minimized.
Show comment
Hide comment
This comment has been minimized.
tasket
Dec 3, 2017
That would definitely interfere. You would need to replace the original script lines.
tasket
commented
Dec 3, 2017
|
That would definitely interfere. You would need to replace the original script lines. |
This comment has been minimized.
Show comment
Hide comment
This comment has been minimized.
boistordu
Dec 3, 2017
aaah so maybe that's the problem then.
So how can I combine both of them? Or should I trust to remove it?
boistordu
commented
Dec 3, 2017
|
aaah so maybe that's the problem then. |
This comment has been minimized.
Show comment
Hide comment
This comment has been minimized.
tasket
Dec 4, 2017
qubes-vpn-handler.sh is a replacement for update-resolv-conf... you should not combine them.
tasket
commented
Dec 4, 2017
|
qubes-vpn-handler.sh is a replacement for update-resolv-conf... you should not combine them. |
This comment has been minimized.
Show comment
Hide comment
This comment has been minimized.
boistordu
Dec 4, 2017
how okey sorry about that. I did not think that it would exactly the same thing. I'm going to try
boistordu
commented
Dec 4, 2017
|
how okey sorry about that. I did not think that it would exactly the same thing. I'm going to try |
This comment has been minimized.
Show comment
Hide comment
This comment has been minimized.
boistordu
Dec 4, 2017
there is now only the second part... still no more than 4 lines in the chain of iptables. I'm going to try the dns name resolving in another vm connected to it
boistordu
commented
Dec 4, 2017
|
there is now only the second part... still no more than 4 lines in the chain of iptables. I'm going to try the dns name resolving in another vm connected to it |
This comment has been minimized.
Show comment
Hide comment
This comment has been minimized.
boistordu
commented
Dec 4, 2017
|
still no luck. did I write something wrong in my lines ? |
This comment has been minimized.
Show comment
Hide comment
This comment has been minimized.
boistordu
commented
Dec 4, 2017
|
not working with debian and fedora |
This comment has been minimized.
Show comment
Hide comment
This comment has been minimized.
boistordu
Dec 4, 2017
Dec 04 01:21:52 VPN-test openvpn[1097]: OPTIONS IMPORT: route options modified
Dec 04 01:21:52 VPN-test openvpn[1097]: OPTIONS IMPORT: route-related options modified
Dec 04 01:21:52 VPN-test kernel: tun: Universal TUN/TAP device driver, 1.6
Dec 04 01:21:52 VPN-test kernel: tun: (C) 1999-2004 Max Krasnyansky <maxk@qualcomm.com>
Dec 04 01:21:52 VPN-test NetworkManager[602]: <info> [1512346912.2977] manager: (tun0): new Tun device (/org/freedesktop/NetworkMan
Dec 04 01:21:52 VPN-test openvpn[1097]: OPTIONS IMPORT: --ip-win32 and/or --dhcp-option options modified
Dec 04 01:21:52 VPN-test openvpn[1097]: OPTIONS IMPORT: peer-id set
Dec 04 01:21:52 VPN-test openvpn[1097]: OPTIONS IMPORT: adjusting link_mtu to 1657
Dec 04 01:21:52 VPN-test openvpn[1097]: OPTIONS IMPORT: data channel crypto options modified
Dec 04 01:21:52 VPN-test openvpn[1097]: Data Channel Encrypt: Cipher 'AES-256-GCM' initialized with 256 bit key
Dec 04 01:21:52 VPN-test openvpn[1097]: Data Channel Decrypt: Cipher 'AES-256-GCM' initialized with 256 bit key
Dec 04 01:21:52 VPN-test openvpn[1097]: ROUTE_GATEWAY 10.137.1.1
Dec 04 01:21:52 VPN-test openvpn[1097]: TUN/TAP device tun0 opened
Dec 04 01:21:52 VPN-test systemd-networkd[299]: tun0: Gained carrier
Dec 04 01:21:52 VPN-test openvpn[1097]: TUN/TAP TX queue length set to 100
Dec 04 01:21:52 VPN-test systemd-timesyncd[500]: Network configuration changed, trying to establish connection.
Dec 04 01:21:52 VPN-test openvpn[1097]: do_ifconfig, tt->did_ifconfig_ipv6_setup=0
Dec 04 01:21:52 VPN-test systemd-resolved[682]: Switching to system DNS server 10.137.1.1.
Dec 04 01:21:52 VPN-test openvpn[1097]: /sbin/ip link set dev tun0 up mtu 1500
Dec 04 01:21:52 VPN-test systemd-networkd[299]: tun0: Gained IPv6LL
Dec 04 01:21:52 VPN-test openvpn[1097]: /sbin/ip addr add dev tun0 10.8.8.31/24 broadcast 10.8.8.255
Dec 04 01:21:52 VPN-test systemd-timesyncd[500]: Network configuration changed, trying to establish connection.
Dec 04 01:21:52 VPN-test systemd-timesyncd[500]: Network configuration changed, trying to establish connection.
Dec 04 01:21:52 VPN-test openvpn[1097]: qubes-vpn-handler.sh up tun0 1500 1585 10.8.8.31 255.255.255.0 init
Dec 04 01:21:52 VPN-test NetworkManager[602]: <info> [1512346912.3193] device (tun0): state change: unmanaged -> unavailable (reaso
Dec 04 01:21:52 VPN-test NetworkManager[602]: <info> [1512346912.3215] keyfile: add connection in-memory (e506bf03-686e-4914-874d-3
Dec 04 01:21:52 VPN-test NetworkManager[602]: <info> [1512346912.3235] device (tun0): state change: unavailable -> disconnected (re
Dec 04 01:21:52 VPN-test NetworkManager[602]: <info> [1512346912.3248] device (tun0): Activation: starting connection 'tun0' (e506b
Dec 04 01:21:52 VPN-test systemd-timesyncd[500]: Network configuration changed, trying to establish connection.
Dec 04 01:21:52 VPN-test NetworkManager[602]: <info> [1512346912.3325] device (tun0): state change: disconnected -> prepare (reason
Dec 04 01:21:52 VPN-test NetworkManager[602]: <info> [1512346912.3356] device (tun0): state change: prepare -> config (reason 'none
Dec 04 01:21:52 VPN-test NetworkManager[602]: <info> [1512346912.3375] device (tun0): state change: config -> ip-config (reason 'no
Dec 04 01:21:52 VPN-test NetworkManager[602]: <info> [1512346912.3397] device (tun0): state change: ip-config -> ip-check (reason '
Dec 04 01:21:52 VPN-test NetworkManager[602]: <info> [1512346912.3420] device (tun0): state change: ip-check -> secondaries (reason
Dec 04 01:21:52 VPN-test NetworkManager[602]: <info> [1512346912.3438] device (tun0): state change: secondaries -> activated (reaso
Dec 04 01:21:52 VPN-test su[1112]: Successful su for user by root
Dec 04 01:21:52 VPN-test su[1112]: + ??? root:user
Dec 04 01:21:52 VPN-test su[1112]: pam_unix(su:session): session opened for user user by (uid=0)
Dec 04 01:21:52 VPN-test systemd[1]: Started Session c5 of user user.
Dec 04 01:21:52 VPN-test systemd-logind[536]: New session c5 of user user.
Dec 04 01:21:52 VPN-test NetworkManager[602]: <info> [1512346912.3730] device (tun0): Activation: successful, device activated.
Dec 04 01:21:52 VPN-test nm-dispatcher[696]: req:4 'up' [tun0]: new request (3 scripts)
Dec 04 01:21:52 VPN-test su[1112]: pam_unix(su:session): session closed for user user
Dec 04 01:21:52 VPN-test openvpn[1097]: /sbin/ip route add someip/32 via 10.137.1.1
Dec 04 01:21:52 VPN-test openvpn[1097]: /sbin/ip route add 0.0.0.0/1 via 10.8.8.1
Dec 04 01:21:52 VPN-test systemd-logind[536]: Removed session c5.
Dec 04 01:21:52 VPN-test openvpn[1097]: /sbin/ip route add 128.0.0.0/1 via 10.8.8.1
Dec 04 01:21:52 VPN-test openvpn[1097]: Initialization Sequence Completed
Dec 04 01:21:52 VPN-test NetworkManager[602]: <info> [1512346912.6016] manager: startup complete
Dec 04 01:21:52 VPN-test systemd[1]: Started Network Manager Wait Online.
Dec 04 01:21:52 VPN-test openvpn[1097]: OPTIONS IMPORT: route options modified
Dec 04 01:21:52 VPN-test openvpn[1097]: OPTIONS IMPORT: route-related options modified
Dec 04 01:21:52 VPN-test kernel: tun: Universal TUN/TAP device driver, 1.6
Dec 04 01:21:52 VPN-test kernel: tun: (C) 1999-2004 Max Krasnyansky <maxk@qualcomm.com>
Dec 04 01:21:52 VPN-test NetworkManager[602]: <info> [1512346912.2977] manager: (tun0): new Tun device (/org/freedesktop/NetworkMan
Dec 04 01:21:52 VPN-test openvpn[1097]: OPTIONS IMPORT: --ip-win32 and/or --dhcp-option options modified
Dec 04 01:21:52 VPN-test openvpn[1097]: OPTIONS IMPORT: peer-id set
Dec 04 01:21:52 VPN-test openvpn[1097]: OPTIONS IMPORT: adjusting link_mtu to 1657
Dec 04 01:21:52 VPN-test openvpn[1097]: OPTIONS IMPORT: data channel crypto options modified
Dec 04 01:21:52 VPN-test openvpn[1097]: Data Channel Encrypt: Cipher 'AES-256-GCM' initialized with 256 bit key
Dec 04 01:21:52 VPN-test openvpn[1097]: Data Channel Decrypt: Cipher 'AES-256-GCM' initialized with 256 bit key
Dec 04 01:21:52 VPN-test openvpn[1097]: ROUTE_GATEWAY 10.137.1.1
Dec 04 01:21:52 VPN-test openvpn[1097]: TUN/TAP device tun0 opened
Dec 04 01:21:52 VPN-test systemd-networkd[299]: tun0: Gained carrier
Dec 04 01:21:52 VPN-test openvpn[1097]: TUN/TAP TX queue length set to 100
Dec 04 01:21:52 VPN-test systemd-timesyncd[500]: Network configuration changed, trying to establish connection.
Dec 04 01:21:52 VPN-test openvpn[1097]: do_ifconfig, tt->did_ifconfig_ipv6_setup=0
Dec 04 01:21:52 VPN-test systemd-resolved[682]: Switching to system DNS server 10.137.1.1.
Dec 04 01:21:52 VPN-test openvpn[1097]: /sbin/ip link set dev tun0 up mtu 1500
Dec 04 01:21:52 VPN-test systemd-networkd[299]: tun0: Gained IPv6LL
Dec 04 01:21:52 VPN-test openvpn[1097]: /sbin/ip addr add dev tun0 10.8.8.31/24 broadcast 10.8.8.255
Dec 04 01:21:52 VPN-test systemd-timesyncd[500]: Network configuration changed, trying to establish connection.
Dec 04 01:21:52 VPN-test systemd-timesyncd[500]: Network configuration changed, trying to establish connection.
Dec 04 01:21:52 VPN-test openvpn[1097]: qubes-vpn-handler.sh up tun0 1500 1585 10.8.8.31 255.255.255.0 init
Dec 04 01:21:52 VPN-test NetworkManager[602]: <info> [1512346912.3193] device (tun0): state change: unmanaged -> unavailable (reaso
Dec 04 01:21:52 VPN-test NetworkManager[602]: <info> [1512346912.3215] keyfile: add connection in-memory (e506bf03-686e-4914-874d-3
Dec 04 01:21:52 VPN-test NetworkManager[602]: <info> [1512346912.3235] device (tun0): state change: unavailable -> disconnected (re
Dec 04 01:21:52 VPN-test NetworkManager[602]: <info> [1512346912.3248] device (tun0): Activation: starting connection 'tun0' (e506b
Dec 04 01:21:52 VPN-test systemd-timesyncd[500]: Network configuration changed, trying to establish connection.
Dec 04 01:21:52 VPN-test NetworkManager[602]: <info> [1512346912.3325] device (tun0): state change: disconnected -> prepare (reason
Dec 04 01:21:52 VPN-test NetworkManager[602]: <info> [1512346912.3356] device (tun0): state change: prepare -> config (reason 'none
Dec 04 01:21:52 VPN-test NetworkManager[602]: <info> [1512346912.3375] device (tun0): state change: config -> ip-config (reason 'no
Dec 04 01:21:52 VPN-test NetworkManager[602]: <info> [1512346912.3397] device (tun0): state change: ip-config -> ip-check (reason '
Dec 04 01:21:52 VPN-test NetworkManager[602]: <info> [1512346912.3420] device (tun0): state change: ip-check -> secondaries (reason
Dec 04 01:21:52 VPN-test NetworkManager[602]: <info> [1512346912.3438] device (tun0): state change: secondaries -> activated (reaso
Dec 04 01:21:52 VPN-test su[1112]: Successful su for user by root
Dec 04 01:21:52 VPN-test su[1112]: + ??? root:user
Dec 04 01:21:52 VPN-test su[1112]: pam_unix(su:session): session opened for user user by (uid=0)
Dec 04 01:21:52 VPN-test systemd[1]: Started Session c5 of user user.
Dec 04 01:21:52 VPN-test systemd-logind[536]: New session c5 of user user.
Dec 04 01:21:52 VPN-test NetworkManager[602]: <info> [1512346912.3730] device (tun0): Activation: successful, device activated.
Dec 04 01:21:52 VPN-test nm-dispatcher[696]: req:4 'up' [tun0]: new request (3 scripts)
Dec 04 01:21:52 VPN-test su[1112]: pam_unix(su:session): session closed for user user
Dec 04 01:21:52 VPN-test openvpn[1097]: /sbin/ip route add someip/32 via 10.137.1.1
Dec 04 01:21:52 VPN-test openvpn[1097]: /sbin/ip route add 0.0.0.0/1 via 10.8.8.1
Dec 04 01:21:52 VPN-test systemd-logind[536]: Removed session c5.
Dec 04 01:21:52 VPN-test openvpn[1097]: /sbin/ip route add 128.0.0.0/1 via 10.8.8.1
Dec 04 01:21:52 VPN-test openvpn[1097]: Initialization Sequence Completed
Dec 04 01:21:52 VPN-test NetworkManager[602]: <info> [1512346912.6016] manager: startup complete
Dec 04 01:21:52 VPN-test systemd[1]: Started Network Manager Wait Online.
boistordu
commented
Dec 4, 2017
•
edited
Edited 2 times
-
boistordu
edited
Dec 4, 2017 (most recent)
-
boistordu
edited
Dec 4, 2017
edited
-
Dec 4, 2017 (most recent) -
Dec 4, 2017
|
This comment has been minimized.
Show comment
Hide comment
This comment has been minimized.
boistordu
commented
Dec 4, 2017
|
at which moment should I receive the dns? maybe we could debug it like that. |
This comment has been minimized.
Show comment
Hide comment
This comment has been minimized.
boistordu
Dec 4, 2017
I reconfirm that with network manager it works and the primary dns is the gateway so in my case 10.8.8.1
so I don't why it doesn't work with your scripts.
boistordu
commented
Dec 4, 2017
|
I reconfirm that with network manager it works and the primary dns is the gateway so in my case 10.8.8.1 |
This comment has been minimized.
Show comment
Hide comment
This comment has been minimized.
tasket
Dec 4, 2017
You enabled Network Manager in the same VM? Network Manager should not be running.
tasket
commented
Dec 4, 2017
|
You enabled Network Manager in the same VM? Network Manager should not be running. |
This comment has been minimized.
Show comment
Hide comment
This comment has been minimized.
boistordu
Dec 4, 2017
boistordu
commented
Dec 4, 2017
|
No it's another vm for manual connection.
Obtenez Outlook pour iOS<https://aka.ms/o0ukef>
…________________________________
From: tasket <notifications@github.com>
Sent: Monday, December 4, 2017 3:19:24 AM
To: QubesOS/qubes-issues
Cc: boistordu; Mention
Subject: Re: [QubesOS/qubes-issues] VPN script problem on Fedora: cannot resolve domain names (#3348)
You enabled Network Manager in the same VM? Network Manager should not be running.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub<#3348 (comment)>, or mute the thread<https://github.com/notifications/unsubscribe-auth/AJFPg4cvOM4b-gmL7oB_EzA1OMm_Av2Dks5s81argaJpZM4QucDC>.
|
This comment has been minimized.
Show comment
Hide comment
This comment has been minimized.
tasket
Dec 4, 2017
A popup window should appear when qubes-vpn-handler.sh is run immediately after connection. Does it?
tasket
commented
Dec 4, 2017
|
A popup window should appear when qubes-vpn-handler.sh is run immediately after connection. Does it? |
This comment has been minimized.
Show comment
Hide comment
This comment has been minimized.
boistordu
Dec 4, 2017
yes it does. Like I said the vpn connection is up and running and so I have the popup notification too.
boistordu
commented
Dec 4, 2017
|
yes it does. Like I said the vpn connection is up and running and so I have the popup notification too. |
This comment has been minimized.
Show comment
Hide comment
This comment has been minimized.
boistordu
Dec 4, 2017
I'm going to try to re-create a new appvm with a new template for VM. Maybe the problem is there.
So should I completely uninstall network-manager package? or just make all services disable and that's enough?
boistordu
commented
Dec 4, 2017
|
I'm going to try to re-create a new appvm with a new template for VM. Maybe the problem is there. |
This comment has been minimized.
Show comment
Hide comment
This comment has been minimized.
tasket
Dec 4, 2017
You don't need to uninstall NM, just don't activate it in the proxyVM by adding it to the VM Settings/Services list.
Another thing you can try is to run qubes-vpn-handler.sh manually after connecting (assign your DNS numbers first):
export vpn_dns="x.x.x.x y.y.y.y"
sudo /rw/config/vpn/qubes-vpn-handler.sh
Then look at the PR-QBS chain with iptables -L -v -t nat
You could also add lines in the script to show what openvpn is actually passing to it; look at the vpn_dns variable.
tasket
commented
Dec 4, 2017
|
You don't need to uninstall NM, just don't activate it in the proxyVM by adding it to the VM Settings/Services list. Another thing you can try is to run qubes-vpn-handler.sh manually after connecting (assign your DNS numbers first): Then look at the PR-QBS chain with You could also add lines in the script to show what openvpn is actually passing to it; look at the vpn_dns variable. |
This comment has been minimized.
Show comment
Hide comment
This comment has been minimized.
boistordu
Dec 4, 2017
okey for network -manager because the services is activated services list into the template @ NetworkManager-dispatcher.service and NetworManager.service so I didn't know if I had to do a systemctl disable or not.
for the variable, by typing env I do'nt get anythiong so where should I get this variable ?
boistordu
commented
Dec 4, 2017
|
okey for network -manager because the services is activated services list into the template @ NetworkManager-dispatcher.service and NetworManager.service so I didn't know if I had to do a systemctl disable or not. for the variable, by typing env I do'nt get anythiong so where should I get this variable ? |
This comment has been minimized.
Show comment
Hide comment
This comment has been minimized.
boistordu
Dec 5, 2017
it's okey it worked. Apparently there was some problem with the network-manager and to restart from the beginning was the good call. Thanks for your help.
boistordu
commented
Dec 5, 2017
|
it's okey it worked. Apparently there was some problem with the network-manager and to restart from the beginning was the good call. Thanks for your help. |
boistordu commentedNov 29, 2017
Qubes OS version:
R3.2
Affected TemplateVMs:
fedora26-minimal
vpn as proxyvm
sudo sg qvpn -c 'ping 8.8.8.8' give me an operation not permitted
and in appvm connected to the proxvm can't resolve domain name but can ping ip adress as 8.8.8.8