Re: [qubes-users] XL VM connectivity to Qubes Network

2018-10-10 Thread 3mptyy
> I believe that is indeed the aim.
> You can either set to 255.255.255.0 or add specific route, as you have
> done. (Did you set a return route on the destination also?)

The return route is automatically added to the Proxy with the vif-route-qubes, 
and the destination send all traffic to the proxy. The vif-route-qubes seems to 
work perfectly, I noticed no difference between a Qube and a HVM using the 
script...

> The next step would be to examine the rules on the proxy to make sure
> that you are allowing the traffic through the ProxyVM. You could listen
> on the interface that's attached to 10.137.0.8 to see if traffic is
> outbound from there.
> 
> unman

I removed all firewall rules (from Proxy and Qube Server), here's the conf :

# iptables -L

Chain INPUT (policy ACCEPT)
target prot opt source   destination

Chain FORWARD (policy ACCEPT)
target prot opt source   destination

Chain OUTPUT (policy ACCEPT)
target prot opt source   destination

Chain QBS-FORWARD (0 references)
target prot opt source   destination

# iptables -t raw --list

Chain PREROUTING (policy ACCEPT)
target prot opt source   destination

Chain OUTPUT (policy ACCEPT)
target prot opt source   destination

Always the same result, Qube client connects to Qube server perfectly, HVM 
doesn't connect to Qube server.

I captured traffic this afternoon and I think it's an ARP problem... Here's a 
working ARP session when I connect from Qube client to Qube Server :

QUBE CLIENT ARP (from its specific vif) :

18:32:09.483319 ARP, Request who-has 10.137.0.12 tell 10.137.0.10, length 28
18:32:09.483502 ARP, Reply 10.137.0.12 is-at 00:16:3e:5e:6c:00, length 28
18:32:09.746948 ARP, Request who-has 10.137.0.10 tell 10.137.0.12, length 28
18:32:09.746970 ARP, Reply 10.137.0.10 is-at fe:ff:ff:ff:ff:ff, length 28

QUBE SERVER ARP (from its specific vif) :

18:32:09.483343 ARP, Request who-has 10.137.0.8 tell 10.137.0.10, length 28
18:32:09.483536 ARP, Reply 10.137.0.8 is-at 00:16:3e:5e:6c:00, length 28
18:32:09.542795 ARP, Request who-has 10.137.0.10 tell 10.137.0.8, length 28
18:32:09.542817 ARP, Reply 10.137.0.10 is-at fe:ff:ff:ff:ff:ff, length 28

--

and here is the ARP session from HVM to Qube Server :

HVM ARP :

18:33:34.793593 ARP, Request who-has 10.137.0.10 tell 10.137.0.200, length 28
18:33:34.793631 ARP, Reply 10.137.0.10 is-at fe:ff:ff:ff:ff:ff, length 28

18:34:06.537570 ARP, Request who-has 10.137.0.10 tell 10.137.0.200, length 28
18:34:06.537609 ARP, Reply 10.137.0.10 is-at fe:ff:ff:ff:ff:ff, length 28

18:34:38.793679 ARP, Request who-has 10.137.0.10 tell 10.137.0.200, length 28
18:34:38.793699 ARP, Reply 10.137.0.10 is-at fe:ff:ff:ff:ff:ff, length 28

QUBE SERVER ARP :

Nothing :(

--

It's like the Proxy does not forward traffic to the destination vif, but 
there's no firewall rule blocking it, so I'm out of ideas...

Other observations : ping is working between HVM and Proxy. No luck between HVM 
and Qube Server. 

I saw that every Qube had the same MAC address (I don't understand how it's 
possible, I'd really appreciate a document explaining how Qubes Networking 
work...) so I tried to set this same MAC address to the HVM, no more luck.

Any help appreciated ! I'm feeling desperate right now :(

-- 
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 qubes-users+unsubscr...@googlegroups.com.
To post to this group, send email to qubes-users@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/133d75e3-bebf-49dd-ac0f-90c3ec680fb1%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


Re: [qubes-users] XL VM connectivity to Qubes Network

2018-10-08 Thread 3mptyy
On Tuesday, September 25, 2018 at 9:24:08 PM UTC+2, 3mp...@gmail.com wrote:
> > Some obvious questions.
> > 
> > You say the interface is correctly configured.
> > Do you have any routes set in the Windows box?
> > Do you see traffic outbound on the 10.137.0.50 iface?
> > 
> > If you sniff traffic inbound on the vif attached to the Windows HVM, do
> > you see anything there? (I mean sniff on the proxyVM)
> 
> Hi Unman, thanks for your help.
> 
> To eliminate some potential Windows issues I chose to boot on a fedora 28 
> live cd in this HVM.
> 
> I configured the eth0 interface with the following command to copy a normal 
> qubes configuration :
> 
> ifconfig eth0 10.137.0.200 (HVM IP) netmask 255.255.255.255 broadcast 
> 10.255.255.255
> route add -host 10.137.0.10 (ProxyVM IP) dev eth0
> route add default gw 10.137.0.10 eth0
> 
> I identified vif14 on ProxyVM, it corresponds to the HVM interace.
> 
> I launched tcpdump -n -i vif14.0 on ProxyVM, telnet from 10.137.0.200 (HVM) 
> to 10.137.0.8 port 8080 (web server on qube I'm trying to reach, working 
> great from a third qube)
> 
> telnet doesn't connect but here's the result of tcpdump :
> 
> https://pastebin.com/QXhyBx4Z
> 
> Any help appreciated

Could someone help me on this issue ? Or explain the right network 
configuration in Qubes 4.0 ? The 255.255.255.255 netmask seems strange to me... 
Is the idea to block all kind of traffic except to the gateway with the route 
add -host commmand ?

-- 
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 qubes-users+unsubscr...@googlegroups.com.
To post to this group, send email to qubes-users@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/9724addd-d087-4f64-ab60-32ce5b7a9437%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


Re: [qubes-users] XL VM connectivity to Qubes Network

2018-09-25 Thread 3mptyy
> Some obvious questions.
> 
> You say the interface is correctly configured.
> Do you have any routes set in the Windows box?
> Do you see traffic outbound on the 10.137.0.50 iface?
> 
> If you sniff traffic inbound on the vif attached to the Windows HVM, do
> you see anything there? (I mean sniff on the proxyVM)

Hi Unman, thanks for your help.

To eliminate some potential Windows issues I chose to boot on a fedora 28 live 
cd in this HVM.

I configured the eth0 interface with the following command to copy a normal 
qubes configuration :

ifconfig eth0 10.137.0.200 (HVM IP) netmask 255.255.255.255 broadcast 
10.255.255.255
route add -host 10.137.0.10 (ProxyVM IP) dev eth0
route add default gw 10.137.0.10 eth0

I identified vif14 on ProxyVM, it corresponds to the HVM interace.

I launched tcpdump -n -i vif14.0 on ProxyVM, telnet from 10.137.0.200 (HVM) to 
10.137.0.8 port 8080 (web server on qube I'm trying to reach, working great 
from a third qube)

telnet doesn't connect but here's the result of tcpdump :

https://pastebin.com/QXhyBx4Z

Any help appreciated

-- 
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 qubes-users+unsubscr...@googlegroups.com.
To post to this group, send email to qubes-users@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/83b2b37d-ea44-41a4-a2f1-1de7c6097005%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


[qubes-users] XL VM connectivity to Qubes Network

2018-09-24 Thread 3mptyy
Hi,

I’m still working on my Qubes 4.0 migration and I’m trying to connect a Windows 
10 XL created VM to Qubes Networking by adding this kind of line in the hvm 
file :

vif = [ 'mac=00:16:3e:5e:6d:11,model=e1000,
ip=10.137.0.50,script=vif-route-qubes,backend=sys-vpn’ ]

The backend is a functional proxy VM created by following the « Set up a 
ProxyVM as a VPN gateway using iptables and CLI scripts » tutorial

The guest VM is a Windows 10 1804 with Xen paravirtual drivers 8.2.1 installed. 
The e1000 is correctly detected as a Xen adapter with link up and configured 
with IP : 10.137.0.50 / 24, no gateway, I’m just trying to access some HTTP 
services in another qube connected to the same proxyVM. Firewall rules are OK 
because it’s working from a third qube connected to the proxyVM.

The Windows 10 VM is acting like it has no connectivy at all. Can’t connect to 
the HTTP server of my qube. I tried removing all firewall rules in proxyVM and 
qube HTTP server and setting ACCEPT policy for all chains, it doesn’t change 
anything so I think it’s not a firewall problem…

I’d be grateful if someone gives me a clue where the problem could be :(

-- 
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 qubes-users+unsubscr...@googlegroups.com.
To post to this group, send email to qubes-users@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/4bd2169e-3271-4a64-b32d-a29ef03be8dd%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


Re: [qubes-users] Assign Sata Device to Qube

2018-09-05 Thread 3mptyy
On Wednesday, August 29, 2018 at 3:15:16 PM UTC+2, unman wrote:
> On Mon, Aug 27, 2018 at 06:56:48AM -0700, Who Cares wrote:
> > 
> > 
> > I got a Question about that 
> > 
> > Somehow I got no templates directory under /etc/qubes?
> 
> You can just create the directory structure as needed.
> > 
> > But I found the xen.xml.
> > 
> > And what does "by-name" mean?
> 
> "by-name" is just a literal directory name.
> You use it to identify configuration files by qube name.
>  
> > Its just about where to put this file so that Qubes pick it up upon boot of 
> > foo. 
> > 
> 
> Yes

Thanks Unman for your explanations ! There are just some small glitches in your 
syntax, here's the right content to put in .xml file (xen.xml and 
not xen/xml and not specifying /dev/xvde but xvde):

{% extends 'libvirt/xen.xml' %} 
{% block devices %} 
{{ super() }} 
 
 
 
 
 
{% endblock %}

-- 
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 qubes-users+unsubscr...@googlegroups.com.
To post to this group, send email to qubes-users@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/40d7c043-ec04-437f-88b3-425cc605dc7d%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


Re: [qubes-users] Custom Configuration files for AppVMs

2018-09-05 Thread 3mptyy
Le vendredi 31 août 2018 19:22:08 UTC+2, airele...@tutanota.com a écrit :
> In Qubes 4.0,  I think the default config for all VMs is:
>/usr/share/qubes/templates/libvirt/xen.xml
> and you can override it for  by placing a config file in 
>   /etc/qubes/templates/libvirt/xen/by-name/.xml
> Simply copying the former to the latter is probably a good place to start.

Thank you for your answer ! Searching this XML template location redirected me 
to this thread which contains a link to qubes dev documentation and a good 
example of what I'm trying to accomplish : 
https://groups.google.com/forum/#!msg/qubes-users/jZnKHg1a4Gs/uKWBK701AgAJ

It's working like a charm now :)

-- 
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 qubes-users+unsubscr...@googlegroups.com.
To post to this group, send email to qubes-users@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/8cd778f7-1307-410c-b087-e7228e143e5b%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


Re: [qubes-users] Custom Configuration files for AppVMs

2018-08-31 Thread 3mptyy
On Tuesday, July 9, 2013 at 4:29:18 AM UTC+2, Marek Marczykowski-Górecki wrote:
> On 29.06.2013 08:23, Olivier Médoc wrote:
> > On 06/29/13 06:58, AndrewX192 wrote:
> >> Is it possible to permanently set or override options in the autogenerated
> >> configuration files, and if so - what is the best way to implement these
> >> changes?
> >>
> > If you change your vm config filename and you edit qubes manager xml file to
> > match the new filename, this file will be considered as custom and won't be
> > generated anymore during the vm startup. Check in 
> > /var/lib/qubes/appvms/yourvm
> > and /var/lib/qubes/qubes.xml.
> > 
> > You will probably have to restart the qubes manager once you changed the 
> > file.
> > I'm not sure about that.
> 
> Qubes manager should automatically detect qubes.xml modification (inotify
> based watch).
> 
> -- 
> Best Regards,
> Marek Marczykowski-Górecki
> Invisible Things Lab

I have the same problem in Qubes 4.0 but I can't find the VM configuration 
file... I tried modifying the qubes.xml file, tried virsh edit the VM with no 
luck, the config file of the VM I can't find is always regenerated when the VM 
starts.

There is a workaround when the VM is started with xl block-attach which is 
working and probably can be automated with qubes-rpc but I'm looking for a more 
elegant way like Olivier's solution for Qubes 4.0

Any directions ?

-- 
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 qubes-users+unsubscr...@googlegroups.com.
To post to this group, send email to qubes-users@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/edced9d8-73ca-48e4-9b50-f0cd4fa5fc5c%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


[qubes-users] X470 and IOMMU Groups...

2018-08-08 Thread 3mptyy
Hi everyone,

actually I'm a happy Qubes 3.2 user on Intel platform for more than a year now !

I'm looking to upgrade my actual Skylake build with an AMD one with the new 
Ryzen Pinnacle Ridge CPU (R7 2700) and installing Qubes 4.0 on the same 
occasion. The Asrock X470 Taichi seems a really nice motherboard for it.

I've found the IOMMU Groups of this motherboard on reddit : 
https://www.reddit.com/r/VFIO/comments/8i8yqq/iommu_groups_for_asrock_taichi_x470/

and it seems there's a big group 13 with LAN, USB and SATA controllers. I 
wonder if the netVM and USB VM will actually be able to passthrough these 
controllers if they are in the same IOMMU Group ?

Any Ryzen / Qubes users can confirm this works OK or this is a no go ?

Thanks for your help !

-- 
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 qubes-users+unsubscr...@googlegroups.com.
To post to this group, send email to qubes-users@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/c359faec-ee8a-4709-9c2d-43f77445e647%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.