Hi,

I am a new user of Qubes OS so apologies in advance if the question here has 
been answered already in a separate topic (there are similar issues) and I 
haven’t discovered this or it is not one suited to this mailing list. I am 
running Qubes 3.2 and attempting to ping from one VM to another VM, 
specifically from a Standalone Windows 7 VM to a Qubes VM based on the Debian 8 
template.

All my VM’s were initially connected in the default manner i.e. to a 
sys-firewall and through to the sys-net VM, both of which are Fedora 23. There 
are no firewall rules on these VMs restricting which IP addresses can be 
accessed.

Current status:
- I am able to ping from my Windows 7 VM (10.137.2.19) to the Firewall VM 
(10.137.1.8) using the IP address visible in the VM Manager

- I am unable to ping the Debian 8 VM (10.137.2.18) from my Windows VM. 

Steps taken:
1) I followed the instructions here 
(https://www.qubes-os.org/doc/qubes-firewall/#enabling-networking-between-two-vms)
 and in the firewall VM’s terminal enter the following iptables rule...

sudo iptables -I FORWARD 2 -s <IP address of Windows 7 VM> -d <IP address of 
Debian 8 VM> -j ACCEPT

… In VM B’s terminal (Debian 8) I entered the following iptables rule...

sudo iptables -I INPUT -s <IP address of Windows 7 VM> -j ACCEPT

...but from here when using the ping function to my Debian 8 VM in the cmd 
prompt in Windows, all packets were lost.

2) As this was not successful I attempted to see if I could connect to VMs from 
an external machine and followed the instructions here 
https://www.qubes-os.org/doc/qubes-firewall/#port-forwarding-to-a-vm-from-the-outside-world.

The Eth0 IP address (192.168.1.6) appeared to be what I should expose the 
service to.

I put the below rule in the sys-net VM’s Terminal...

iptables -t nat -A PREROUTING -i eth0 -p tcp --dport 443 -d 192.168.x.x -j DNAT 
--to-destination 10.137.1.x

...and this rule into the sys-firewall VM’s Terminal

iptables -I FORWARD 2 -i eth0 -d 10.137.1.x -p tcp --dport 443 -m conntrack 
--ctstate NEW -j ACCEPT

But using ping or Telnet resulted in lost packets and failed to increase the 
counters when using the iptables -t nat -L -v -n command in the sys-firewall 
VM's terminal.

3) With this not being successful either I attempted to add a “sys-proxy” VM as 
described here 
https://groups.google.com/forum/#!searchin/qubes-users/intervm%7Csort:relevance/qubes-users/lA2SgPcV9fU/U969uapYAAAJ
 and entered the following in the new sys-proxy VM's terminal:

iptables -I FORWARD 1 -i vif+ -o vif+ -s $intervm_internalnet/24 -d 
$intervm_internalnet/24 -m state --state NEW -p tcp -m tcp -j ACCEPT

iptables -I FORWARD 1 -i vif+ -o vif+ -s $intervm_internalnet/24 -d 
$intervm_internalnet/24 -p udp -m udp -j ACCEPT

After this, I was still unable to ping the Debian 8 VM from my Windows VM.

Questions:

1) Are there any obvious errors in the steps I took and does anyone have any 
suggestions how I can resolve this issue?

2)  There are a number of other incidences of what seemed to be a similar issue 
here: 
https://groups.google.com/forum/?nomobile=true#!msg/qubes-users/59kOjfQFBI4/bjS47-jJJgAJ,
 https://groups.google.com/forum/#!msg/qubes-users/vSyUaOSloYU/ONZNJlhrBAAJ. 
Are the enabling networking between VMs steps described here still correct and 
applicable for Qubes 3.2?

3) The IP address assignment suggests that the VMs are on the same network – 
the Subnet Mask is 255.255.255.0 so surely any devices with an IP address of 
10.137.2.x would be able to communicate with each other? What is unique in Xen 
/ Qubes that stops this?

4) Is there a way in which the current routing rules can be displayed and reset 
back to the default if required?

-- 
You received this message because you are subscribed to the Google Groups 
"qubes-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to [email protected].
To post to this group, send email to [email protected].
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/0514e15b-950e-4636-95f7-849fc5671fc1%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Reply via email to