On 08/21/2017 07:32 PM, PhR wrote:
Chain ciscovpn (3 references)
target prot opt source destination
ACCEPT all -- anywhere anywhere state
RELATED,ESTABLISHED
ACCEPT all -- anywhere anywhere
ACCEPT all -- anywhere anywhere
ACCEPT udp -- anywhere anywhere udp
spt:bootpc dpt:bootps
ACCEPT udp -- anywhere anywhere udp
spt:bootps dpt:bootpc
ACCEPT udp -- anywhere anywhere udp
spt:dhcpv6-client dpt:dhcpv6-server
ACCEPT udp -- anywhere anywhere udp
spt:dhcpv6-server dpt:dhcpv6-client
ACCEPT tcp -- 10.137.2.26 213.xxx.xxx.xxx tcp
dpt:https
ACCEPT tcp -- 213.xxx.xxx.xxx 10.137.2.26 tcp
spt:https
ACCEPT udp -- 10.137.2.26 213.xxx.xxx.xxx udp
dpt:https
ACCEPT udp -- 213.xxx.xxx.xxx 10.137.2.26 udp
spt:https
RETURN all -- 10.137.2.26 anywhere
RETURN all -- anywhere 10.137.2.26
RETURN all -- 10.137.2.26 10.137.2.26
RETURN all -- 10.137.2.26 10.137.2.26
RETURN udp -- 10.137.2.26 224.0.0.251 udp
dpt:mdns
RETURN udp -- 10.137.2.26 after launching it I can
224.0.0.251 udp dpt:mdns
RETURN udp -- 10.137.2.26 239.255.255.250 udp
dpt:ssdp
RETURN udp -- 10.137.2.26 239.255.255.250 udp
dpt:ssdp
RETURN all -- anywhere base-address.mcast.net/4
RETURN all -- 10.137.2.26 base-address.mcast.net/4
RETURN all -- anywhere 255.255.255.255
RETURN all -- 10.137.2.26 255.255.255.255
RETURN all -- 172.21.2.13 aaaaa.de/24
RETURN all -- isys-team.de/24 172.21.2.13
RETURN all -- 172.21.2.13 192.168.3.0/24
RETURN all -- 192.168.3.0/24 172.21.2.13
RETURN all -- 172.21.2.13 10.5.48.0/24
RETURN all -- 10.5.48.0/24 172.21.2.13
RETURN all -- 172.21.2.13 192.168.5.0/24
RETURN all -- 192.168.5.0/24 172.21.2.13
RETURN all -- 172.21.2.13 192.168.100.0/24
RETURN all -- 192.168.100.0/24 172.21.2.13
RETURN all -- 172.21.2.13 vsrv-dc-3.xxx.yyy.de
RETURN all -- vsrv-dc-3.xxx.yyy.de 172.21.2.13
RETURN all -- 172.21.2.13 vsrv-dc-2.xxx.yyy.de
RETURN all -- vsrv-dc-2.xxx.yyy.de 172.21.2.13
RETURN udp -- 172.21.2.13 anywhere udp
dpt:domain
RETURN udp -- anywhere 172.21.2.13 udp
spt:domain
RETURN all -- anywhere 255.255.255.255
RETURN all -- 172.21.2.13 255.255.255.255
DROP all -- anywhere anywhere
DROP all -- anywhere anywhere
Chain ciscovpnfw (3 references)
target prot opt source destination
First, I surmise that 10.137.2.26 is the proxyVM address, not appVM.
Its hard to see the problem clearly because of the complexity of what
its adding, but I think your appVM packets are probably hitting the 2
DROP targets at the end of 'ciscovpn' chain. This may be because the
chain explicitly allows packets from 'source' address of your VPN
proxyVM, but there is nothing explicitly in that chain allowing 'source'
addresses for downstream appVMs. This is a problem when 'ciscovpn' chain
is called from the FORWARD chain.
As a test remedy you could try the following in the proxyVM (_after_
your appVM is already running):
$ sudo iptables -I FORWARD -i vif+ -j ACCEPT
...then try connections from the appVM.
This will cause anything coming from downstream VMs to be accepted for
forwarding (which is OK if you don't intend to use Qubes firewall
restrictions in appVM Settings). A full long-term solution would involve
reconciling the cisco firewall commands with the Qubes firewall service
(would be ideal if Anyconnect used a firewall script and it could be
located in the system, then you could have the right commands issued
from /rw/config/qubes-firewall-user-script).
I have already tried to use the openconnect plugin for network
manager, but when I click on Add in the network manager and choose VPN
and then "Cisco AnyConnect Compatible VPN (openconnect)" I get a new
windows but can't add any information here as every field looks
disabled :-/ ?
Working with OpenConnect would be great.
There is also a GUI part that needs to be installed:
NetworkManager-openconnect-gnome in Fedora.
I also thought that is Qubes Best practise to use a dedicated VPN
Proxy VM vs. launching VPN from within an AppVM ?
Should be OK for a work-only VPN where your appVM is also work-only; Its
a different threat model than an Internet-focused VPN.
-
Finally, I should mention leak prevention measures. If you are able to
get the VPN to function with proxyVM + appVMs, you can then add these
commands in proxyVM to prevent appVMs from having non-VPN access:
iptables -I FORWARD -o eth0 -j DROP
iptables -I FORWARD -i eth0 -j DROP
These need to show up at the _top_ of the FORWARD chain, which is why
'-I' insert is used; You can ensure they'll be at the top by executing
them last after a connection is made (probably from
/rw/config/qubes-firewall-user-script).
--
Chris Laprise, tas...@posteo.net
https://twitter.com/ttaskett
PGP: BEE2 20C5 356E 764A 73EB 4AB3 1DC4 D106 F07F 1886
--
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/ba46841a-0dd1-b974-af7b-257fdb638c5e%40posteo.net.
For more options, visit https://groups.google.com/d/optout.
