You are not logged in.
Hi there,
I installed a Windows 10 guest with the help of this guide: https://wiki.archlinux.org/index.php/PC … h_via_OVMF
When I use the vpnfailsafe script, I cannot get a network connection to or from the guest.
The ip address of the guest is according to Windows ipconfig 169.254.227.13, so I added it to the vpnfailsafe scripts private_net variable.
Do you know how to change the script to allow a connection to and from the guest?
Output of "iptables -L":
Chain INPUT (policy ACCEPT)
target prot opt source destination
VPNFAILSAFE_INPUT all -- anywhere anywhere
ACCEPT udp -- anywhere anywhere udp dpt:domain
ACCEPT tcp -- anywhere anywhere tcp dpt:domain
ACCEPT udp -- anywhere anywhere udp dpt:bootps
ACCEPT tcp -- anywhere anywhere tcp dpt:bootps
Chain FORWARD (policy ACCEPT)
target prot opt source destination
VPNFAILSAFE_FORWARD all -- anywhere anywhere
ACCEPT all -- anywhere 192.168.122.0/24 ctstate RELATED,ESTABLISHED
ACCEPT all -- 192.168.122.0/24 anywhere
ACCEPT all -- anywhere anywhere
REJECT all -- anywhere anywhere reject-with icmp-port-unreachable
REJECT all -- anywhere anywhere reject-with icmp-port-unreachable
Chain OUTPUT (policy ACCEPT)
target prot opt source destination
VPNFAILSAFE_OUTPUT all -- anywhere anywhere
ACCEPT udp -- anywhere anywhere udp dpt:bootpc
Chain VPNFAILSAFE_FORWARD (1 references)
target prot opt source destination
RETURN all -- anywhere 127.0.0.0/8
RETURN all -- anywhere 10.0.0.0/8
RETURN all -- anywhere 172.16.0.0/12
RETURN all -- anywhere 192.168.0.0/16
RETURN all -- anywhere 169.254.0.0/16
RETURN all -- anywhere anywhere
DROP all -- anywhere anywhere
Chain VPNFAILSAFE_INPUT (1 references)
target prot opt source destination
ACCEPT tcp -- ch.proxy.sh anywhere tcp spt:843 ctstate RELATED,ESTABLISHED
ACCEPT tcp -- ch.proxy.sh anywhere tcp spt:843 ctstate RELATED,ESTABLISHED
ACCEPT tcp -- ch.proxy.sh anywhere tcp spt:843 ctstate RELATED,ESTABLISHED
ACCEPT tcp -- ch.proxy.sh anywhere tcp spt:843 ctstate RELATED,ESTABLISHED
RETURN all -- 10.8.12.5 anywhere
RETURN all -- 127.0.0.0/8 anywhere
RETURN all -- 10.0.0.0/8 anywhere
RETURN all -- 172.16.0.0/12 anywhere
RETURN all -- 192.168.0.0/16 anywhere
RETURN all -- 169.254.0.0/16 anywhere
DROP all -- 127.0.0.0/8 anywhere
DROP all -- 10.0.0.0/8 anywhere
DROP all -- 172.16.0.0/12 anywhere
DROP all -- 192.168.0.0/16 anywhere
DROP all -- 169.254.0.0/16 anywhere
RETURN all -- anywhere anywhere
DROP all -- anywhere anywhere
Chain VPNFAILSAFE_OUTPUT (1 references)
target prot opt source destination
ACCEPT tcp -- anywhere ch.proxy.sh tcp dpt:843 ctstate NEW,RELATED,ESTABLISHED
ACCEPT tcp -- anywhere ch.proxy.sh tcp dpt:843 ctstate NEW,RELATED,ESTABLISHED
ACCEPT tcp -- anywhere ch.proxy.sh tcp dpt:843 ctstate NEW,RELATED,ESTABLISHED
ACCEPT tcp -- anywhere ch.proxy.sh tcp dpt:843 ctstate NEW,RELATED,ESTABLISHED
RETURN all -- anywhere 10.8.12.5
RETURN all -- anywhere 127.0.0.0/8
RETURN all -- anywhere 10.0.0.0/8
RETURN all -- anywhere 172.16.0.0/12
RETURN all -- anywhere 192.168.0.0/16
RETURN all -- anywhere 169.254.0.0/16
RETURN all -- anywhere anywhere
DROP all -- anywhere anywhere
Output of "iptables-save":
# Generated by iptables-save v1.6.0 on Sun Nov 13 12:31:23 2016
*mangle
:PREROUTING ACCEPT [1099844:1336244072]
:INPUT ACCEPT [1099709:1336233387]
:FORWARD ACCEPT [0:0]
:OUTPUT ACCEPT [731248:106529157]
:POSTROUTING ACCEPT [731229:106527848]
-A POSTROUTING -o virbr0 -p udp -m udp --dport 68 -j CHECKSUM --checksum-fill
COMMIT
# Completed on Sun Nov 13 12:31:23 2016
# Generated by iptables-save v1.6.0 on Sun Nov 13 12:31:23 2016
*nat
:PREROUTING ACCEPT [119:12884]
:INPUT ACCEPT [19:1850]
:OUTPUT ACCEPT [2176:138178]
:POSTROUTING ACCEPT [2162:137284]
-A POSTROUTING -s 192.168.122.0/24 -d 224.0.0.0/24 -j RETURN
-A POSTROUTING -s 192.168.122.0/24 -d 255.255.255.255/32 -j RETURN
-A POSTROUTING -s 192.168.122.0/24 ! -d 192.168.122.0/24 -p tcp -j MASQUERADE --to-ports 1024-65535
-A POSTROUTING -s 192.168.122.0/24 ! -d 192.168.122.0/24 -p udp -j MASQUERADE --to-ports 1024-65535
-A POSTROUTING -s 192.168.122.0/24 ! -d 192.168.122.0/24 -j MASQUERADE
COMMIT
# Completed on Sun Nov 13 12:31:23 2016
# Generated by iptables-save v1.6.0 on Sun Nov 13 12:31:23 2016
*filter
:INPUT ACCEPT [196865:204238069]
:FORWARD ACCEPT [0:0]
:OUTPUT ACCEPT [136280:8358677]
:VPNFAILSAFE_FORWARD - [0:0]
:VPNFAILSAFE_INPUT - [0:0]
:VPNFAILSAFE_OUTPUT - [0:0]
-A INPUT -j VPNFAILSAFE_INPUT
-A INPUT -i virbr0 -p udp -m udp --dport 53 -j ACCEPT
-A INPUT -i virbr0 -p tcp -m tcp --dport 53 -j ACCEPT
-A INPUT -i virbr0 -p udp -m udp --dport 67 -j ACCEPT
-A INPUT -i virbr0 -p tcp -m tcp --dport 67 -j ACCEPT
-A FORWARD -j VPNFAILSAFE_FORWARD
-A FORWARD -d 192.168.122.0/24 -o virbr0 -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT
-A FORWARD -s 192.168.122.0/24 -i virbr0 -j ACCEPT
-A FORWARD -i virbr0 -o virbr0 -j ACCEPT
-A FORWARD -o virbr0 -j REJECT --reject-with icmp-port-unreachable
-A FORWARD -i virbr0 -j REJECT --reject-with icmp-port-unreachable
-A OUTPUT -j VPNFAILSAFE_OUTPUT
-A OUTPUT -o virbr0 -p udp -m udp --dport 68 -j ACCEPT
-A VPNFAILSAFE_FORWARD -d 127.0.0.0/8 ! -o tun0 -j RETURN
-A VPNFAILSAFE_FORWARD -d 10.0.0.0/8 ! -o tun0 -j RETURN
-A VPNFAILSAFE_FORWARD -d 172.16.0.0/12 ! -o tun0 -j RETURN
-A VPNFAILSAFE_FORWARD -d 192.168.0.0/16 ! -o tun0 -j RETURN
-A VPNFAILSAFE_FORWARD -d 169.254.0.0/16 ! -o tun0 -j RETURN
-A VPNFAILSAFE_FORWARD -o tun0 -j RETURN
-A VPNFAILSAFE_FORWARD -j DROP
-A VPNFAILSAFE_INPUT -s 179.43.189.28/32 -i enp0s31f6 -p tcp -m tcp --sport 843 -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT
-A VPNFAILSAFE_INPUT -s 141.255.161.181/32 -i enp0s31f6 -p tcp -m tcp --sport 843 -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT
-A VPNFAILSAFE_INPUT -s 37.235.50.42/32 -i enp0s31f6 -p tcp -m tcp --sport 843 -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT
-A VPNFAILSAFE_INPUT -s 178.209.52.74/32 -i enp0s31f6 -p tcp -m tcp --sport 843 -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT
-A VPNFAILSAFE_INPUT -s 10.8.12.5/32 -i tun0 -j RETURN
-A VPNFAILSAFE_INPUT -s 127.0.0.0/8 ! -i tun0 -j RETURN
-A VPNFAILSAFE_INPUT -s 10.0.0.0/8 ! -i tun0 -j RETURN
-A VPNFAILSAFE_INPUT -s 172.16.0.0/12 ! -i tun0 -j RETURN
-A VPNFAILSAFE_INPUT -s 192.168.0.0/16 ! -i tun0 -j RETURN
-A VPNFAILSAFE_INPUT -s 169.254.0.0/16 ! -i tun0 -j RETURN
-A VPNFAILSAFE_INPUT -s 127.0.0.0/8 -i tun0 -j DROP
-A VPNFAILSAFE_INPUT -s 10.0.0.0/8 -i tun0 -j DROP
-A VPNFAILSAFE_INPUT -s 172.16.0.0/12 -i tun0 -j DROP
-A VPNFAILSAFE_INPUT -s 192.168.0.0/16 -i tun0 -j DROP
-A VPNFAILSAFE_INPUT -s 169.254.0.0/16 -i tun0 -j DROP
-A VPNFAILSAFE_INPUT -i tun0 -j RETURN
-A VPNFAILSAFE_INPUT -j DROP
-A VPNFAILSAFE_OUTPUT -d 179.43.189.28/32 -o enp0s31f6 -p tcp -m tcp --dport 843 -m conntrack --ctstate NEW,RELATED,ESTABLISHED -j ACCEPT
-A VPNFAILSAFE_OUTPUT -d 141.255.161.181/32 -o enp0s31f6 -p tcp -m tcp --dport 843 -m conntrack --ctstate NEW,RELATED,ESTABLISHED -j ACCEPT
-A VPNFAILSAFE_OUTPUT -d 37.235.50.42/32 -o enp0s31f6 -p tcp -m tcp --dport 843 -m conntrack --ctstate NEW,RELATED,ESTABLISHED -j ACCEPT
-A VPNFAILSAFE_OUTPUT -d 178.209.52.74/32 -o enp0s31f6 -p tcp -m tcp --dport 843 -m conntrack --ctstate NEW,RELATED,ESTABLISHED -j ACCEPT
-A VPNFAILSAFE_OUTPUT -d 10.8.12.5/32 -o tun0 -j RETURN
-A VPNFAILSAFE_OUTPUT -d 127.0.0.0/8 ! -o tun0 -j RETURN
-A VPNFAILSAFE_OUTPUT -d 10.0.0.0/8 ! -o tun0 -j RETURN
-A VPNFAILSAFE_OUTPUT -d 172.16.0.0/12 ! -o tun0 -j RETURN
-A VPNFAILSAFE_OUTPUT -d 192.168.0.0/16 ! -o tun0 -j RETURN
-A VPNFAILSAFE_OUTPUT -d 169.254.0.0/16 ! -o tun0 -j RETURN
-A VPNFAILSAFE_OUTPUT -o tun0 -j RETURN
-A VPNFAILSAFE_OUTPUT -j DROP
COMMIT
# Completed on Sun Nov 13 12:31:23 2016
Last edited by sutree (2016-11-13 11:34:53)
Offline
"iptables -L" misses essential details, such as the order of the rules - show the output of "iptables-save" instead.
Offline
Alright, I added the initial post with the output of "iptables-save".
Offline
With rules like this:
-A VPNFAILSAFE_FORWARD -d 127.0.0.0/8 ! -o tun0 -j RETURN
I would question the sanity of the ruleset author - it looks half-baked. The rules would be simpler to understand, and also more efficient, if they used the standard method of rejecting by default, with explicit acceptances. 127.0.0.0/8 is only for "lo" (loopback) interface, so it's a very easy decision.
Use logndrop, rather than "DROP", and you can help to debug those tedious rules yourself
Offline
I installed a Windows 10 guest with the help of this guide: https://wiki.archlinux.org/index.php/PC … h_via_OVMF
When I use the vpnfailsafe script, I cannot get a network connection to or from the guest.
The ip address of the guest is according to Windows ipconfig 169.254.227.13, so I added it to the vpnfailsafe scripts private_net variable.Do you know how to change the script to allow a connection to and from the guest?
Is networking working without the vpn and/or vpnfailsafe ?
Quoting wikipedia: 169.254.0.0/16 - used for link-local addresses between two hosts on a single link when no IP address is otherwise specified, such as would have normally been retrieved from a DHCP server.
This may not be about the firewall at all...
Offline
Yes, networking works just fine without the script.
Offline
Yes, networking works just fine without the script.
vpnfailsafe blocks traffic to DNS servers outside the VPN. If you're testing connectivity in a way that relies on domain name resolution and your guest system is not using the DNS servers pushed by your VPN provider, it will look like networking is not working. Let's eliminate that possibility. Try connecting somewhere from the guest system, only using the IP, not a domain. Or configure the DNS servers on the guest system to match post-vpnfailsafe /etc/resolv.conf from your host.
Last edited by foobarbaz (2016-11-17 23:09:17)
Offline
I'm using qemu+kvm with vpnfailsfe with no issues. As reference (maybe this will help), here's how I start an Alpine VM:
$ qemu-system-x86_64 alpine.qcow2 -boot c -net nic -net user -m 256 -localtime --enable-kvm
The guest gets an IP in the 10.0.2.0/24 network and the default route and the nameserver are set to the host's IP on that network. Pings are not getting through, but otherwise networking is fine.
I've never used Windows guests, but if you're not using -net nic, maybe it's worth looking into. It seems to be the simplest of the available choices.
Offline