proxy vm as a vpn gateway (problem)

[ipet...@gmail.com]

Hi Everyone!

I tried to set up my proxy vm as a vpn gateway. I followed the "How to setup a Proxy VM as a VPN Gateway" (step by step). The proxyvm (called vpnvm) successfully established the vpn connection to the server. Unfortunatelly the trusted vm didn't use the vpn tunnel. (on the trusted vm the network vm is vpnvm)

What is the problem? What did I do wrong?

topology:

server ------------------ net vm ------------ firewall vm ----------------- vpn vm (proxyvm) ----------------- trusted vm
        |<------------------------------------------------------------------------->|

                                tunnel

[7v5w7go9ub0o]

After starting the proxy VM an icon will appear in the (KDE) tray  - but that is the vm only.

You need to rt-click that icon and direct it to connect to the VPN server. When properly connected, a "padlock" will appear within the icon window- indicating both the functioning VM and the VPN connection.

HTH

[ipet...@gmail.com]

Yes I did it. The vpn connection established and the connection information was correct. I saw the "padlock".... My problem is the traffic of the trusted vm is not routed to the vpn tunnel.

[7v5w7go9ub0o]

On 09/21/14 06:36, ipet...@gmail.com wrote:
> Yes I did it. The vpn connection established and the connection information
> was correct. I saw the "padlock".... My problem is the traffic of the
> trusted vm is not routed to the vpn tunnel.
>
> 2014. szeptember 21., vasárnap 1:07:15 UTC+2 időpontban 7v5w7go9ub0o a
> következőt írta:
>>

>> On 09/20/14 16:43, ipet...@gmail.com <javascript:> wrote:
>>> Hi Everyone!
>>>
>>> I tried to set up my proxy vm as a vpn gateway. I followed the "How
>>> to setup a Proxy VM as a VPN Gateway" (step by step). The proxyvm
>>> (called vpnvm) successfully established the vpn connection to the
>>> server. Unfortunatelly the trusted vm didn't use the vpn tunnel. (on
>>> the trusted vm the network vm is vpnvm)
>>>
>>> What is the problem? What did I do wrong?
>>>
>>> topology:
>>>
>>> server ------------------ net vm ------------ firewall vm
>>> ----------------- vpn vm (proxyvm) ----------------- trusted vm
>>>
>>>
>> |<------------------------------------------------------------------------->|
>>>
>> tunnel
>>
>>
>> After starting the proxy VM an icon will appear in the (KDE) tray - but
>> that is the vm only.
>>
>> You need to rt-click that icon and direct it to connect to the VPN server.
>> When properly connected, a "padlock" will appear within the icon window-
>> indicating both the functioning VM and the VPN connection.
>>
>> HTH
>>
>>
>>

IIUC, the padlock means that the VPN - as configured - is functioning
properly, which suggests that it is misconfigured!? Perhaps left-click
the icon; follow the vpn connections to configure vpn; validate or
delete and re-add info.

I suspect you may have done all of this, in which case I can not help.
If deleting and replacing fails, you might want to ping Marek.

[mihaig...@gmail.com]

The problem may be the proxyvm does not masquerade properly packets from your trusted vm. At least, this was a problem for me.
Try pinging server from your vpnvm, see if it replies.
If it does not, tunnel does not even work. If it does, try pinging server from trusted vm. If no reply, remove default masquerade rule on proxyvm and manually add masque/snat rule via vpn interface (meaning all packets coming from trusted vm going via internal net(where server is) should use as source ip the address of the vpn interface on proxyvm, not the address of trustedvm)).

If you have a different problem, you can always use tcpdump, wireshark to see exactly what the problem is.

[Zrubi]

It is really hard to help without more info:
- What kind of VPN are You using?
- after successful connected do you see the new routing in the VPN GW?
route -n
- did you get DNS info from the VPN server?
- the VPN plugin handle it correctly?
cat /etc/resolv.conf
- the qubes related DNS masquerading correct (in the VPN GW)?
iptables -L -n -t nat


usually the #1 problem is the missing DNS info, so first try to ping (or
reach) the server by IP instead of DNS. first from the VPN GW, if it
works, do the same check from the trusted VM...



--
Zrubi

[ipet...@gmail.com]

Connection information (vpn vm)

VPN type openvpn
VPN Gateway gw.vpn.autistici.org

IPV4

IP address 10.19.47.10
Broadcast Address 10.19.47.10
Subent Mask 255.255.255.255
Default route 91.121.204.114
Primary DNS 10.19.0.1

route -n

[user@vpn ~]$ route -n          
Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
0.0.0.0         10.137.2.1      0.0.0.0         UG    0      0        0 eth0
0.0.0.0         10.19.47.9      0.0.0.0         UG    1024   0        0 tun0
10.19.0.1       10.19.47.9      255.255.255.255 UGH   1024   0        0 tun0
10.19.47.9      0.0.0.0         255.255.255.255 UH    0      0        0 tun0
10.137.3.1      0.0.0.0         255.255.255.255 UH    1024   0        0 eth0
10.137.3.7      0.0.0.0         255.255.255.255 UH    32746  0   

cat /etc/resolv.conf

[user@vpn ~]$ cat /etc/resolv.conf
# Generated by NetworkManager
nameserver 10.19.0.1

iptables -L -n -t nat

Chain PREROUTING (policy ACCEPT)
target     prot opt source               destination        
PR-QBS     all  --  0.0.0.0/0            0.0.0.0/0          
PR-QBS-SERVICES  all  --  0.0.0.0/0            0.0.0.0/0          

Chain INPUT (policy ACCEPT)
target     prot opt source               destination        

Chain OUTPUT (policy ACCEPT)
target     prot opt source               destination        

Chain POSTROUTING (policy ACCEPT)
target     prot opt source               destination        
ACCEPT     all  --  0.0.0.0/0            0.0.0.0/0          
ACCEPT     all  --  0.0.0.0/0            0.0.0.0/0          
MASQUERADE  all  --  0.0.0.0/0            0.0.0.0/0          

Chain PR-QBS (1 references)
target     prot opt source               destination        
DNAT       udp  --  0.0.0.0/0            10.137.3.1           udp dpt:53 to:10.19.0.1

Chain PR-QBS-SERVICES (1 references)
target     prot opt source               destination 

vpn vm

[user@vpn ~]$ ping 91.121.204.114
PING 91.121.204.114 (91.121.204.114) 56(84) bytes of data.
64 bytes from 91.121.204.114: icmp_seq=1 ttl=51 time=34.2 ms
64 bytes from 91.121.204.114: icmp_seq=2 ttl=51 time=46.8 ms
64 bytes from 91.121.204.114: icmp_seq=3 ttl=51 time=39.0 ms
64 bytes from 91.121.204.114: icmp_seq=4 ttl=51 time=35.2 ms
^C
--- 91.121.204.114 ping statistics ---
4 packets transmitted, 4 received, 0% packet loss, time 3005ms
rtt min/avg/max/mdev = 34.265/38.845/46.831/4.955 ms

trusted vm

[user@trusted ~]$ ping 91.121.204.114
PING 91.121.204.114 (91.121.204.114) 56(84) bytes of data.
64 bytes from 91.121.204.114: icmp_seq=1 ttl=50 time=42.0 ms
64 bytes from 91.121.204.114: icmp_seq=2 ttl=50 time=34.6 ms
64 bytes from 91.121.204.114: icmp_seq=3 ttl=50 time=32.7 ms
64 bytes from 91.121.204.114: icmp_seq=4 ttl=50 time=253 ms
64 bytes from 91.121.204.114: icmp_seq=5 ttl=50 time=36.4 ms
^X^C
--- 91.121.204.114 ping statistics ---
5 packets transmitted, 5 received, 0% packet loss, time 4005ms
rtt min/avg/max/mdev = 32.708/79.857/253.467/86.860 ms

[Zrubi]

On 09/21/14 19:44, ipet...@gmail.com wrote:
> *Connection information (vpn vm)*

>
> VPN type openvpn
> VPN Gateway gw.vpn.autistici.org
>
> IPV4
>
> IP address 10.19.47.10
> Broadcast Address 10.19.47.10
> Subent Mask 255.255.255.255
> Default route 91.121.204.114
> Primary DNS 10.19.0.1
>

> *route -n
> *

> [user@vpn ~]$ route -n
> Kernel IP routing table
> Destination Gateway Genmask Flags Metric Ref Use
> Iface
> 0.0.0.0 10.137.2.1 0.0.0.0 UG 0 0 0 eth0
> 0.0.0.0 10.19.47.9 0.0.0.0 UG 1024 0 0 tun0
> 10.19.0.1 10.19.47.9 255.255.255.255 UGH 1024 0 0 tun0
> 10.19.47.9 0.0.0.0 255.255.255.255 UH 0 0 0 tun0
> 10.137.3.1 0.0.0.0 255.255.255.255 UH 1024 0 0 eth0
> 10.137.3.7 0.0.0.0 255.255.255.255 UH 32746 0
>

> *cat /etc/resolv.conf*

>
> [user@vpn ~]$ cat /etc/resolv.conf
> # Generated by NetworkManager
> nameserver 10.19.0.1
>

> *iptables -L -n -t nat *
.
.
.

>
> Chain PR-QBS (1 references)
> target prot opt source destination
> DNAT udp -- 0.0.0.0/0 10.137.3.1 udp dpt:53
> to:10.19.0.1

It seem all fine.


The only 'problem' is that your server try to route everything trough
the VPN (try to set a new default gw) and this (pretty normal anyway)
situation is not handled correctly due to Qubes Proxy VMs are using
double default route (for some reason) which is incompatible with the
NetworkManager VPN plugins.


Please confirm this double routing by this command:
route -n
BEFORE You connecting your VPN.


For a workaround:
You can try to remove that remaining bad default route in the Proxy VM
by this command:
sudo route del default gw 10.137.2.1


@Marek
Can You tell me why we need that double default route please?


--
Zrubi

[Zrubi]

On 09/21/14 19:44, ipet...@gmail.com wrote:

> *vpn vm*

>
> [user@vpn ~]$ ping 91.121.204.114
> PING 91.121.204.114 (91.121.204.114) 56(84) bytes of data.
> 64 bytes from 91.121.204.114: icmp_seq=1 ttl=51 time=34.2 ms
> 64 bytes from 91.121.204.114: icmp_seq=2 ttl=51 time=46.8 ms
> 64 bytes from 91.121.204.114: icmp_seq=3 ttl=51 time=39.0 ms
> 64 bytes from 91.121.204.114: icmp_seq=4 ttl=51 time=35.2 ms
> ^C
> --- 91.121.204.114 ping statistics ---
> 4 packets transmitted, 4 received, 0% packet loss, time 3005ms
> rtt min/avg/max/mdev = 34.265/38.845/46.831/4.955 ms
>

> *trusted vm
> *

> [user@trusted ~]$ ping 91.121.204.114
> PING 91.121.204.114 (91.121.204.114) 56(84) bytes of data.
> 64 bytes from 91.121.204.114: icmp_seq=1 ttl=50 time=42.0 ms
> 64 bytes from 91.121.204.114: icmp_seq=2 ttl=50 time=34.6 ms
> 64 bytes from 91.121.204.114: icmp_seq=3 ttl=50 time=32.7 ms
> 64 bytes from 91.121.204.114: icmp_seq=4 ttl=50 time=253 ms
> 64 bytes from 91.121.204.114: icmp_seq=5 ttl=50 time=36.4 ms
> ^X^C
> --- 91.121.204.114 ping statistics ---
> 5 packets transmitted, 5 received, 0% packet loss, time 4005ms
> rtt min/avg/max/mdev = 32.708/79.857/253.467/86.860 ms
>

While your VPN is really fine, you are ping the wrong address.
Try to ping the given DNS server:
10.19.0.1

and see if its works.


--
Zrubi

[Marek Marczykowski-Górecki]

We do not. I think NetworkManager is responsible for the second default gw (it
doesn't notice that it is already configured). I'll look at it closer.

--
Best Regards,
Marek Marczykowski-Górecki
Invisible Things Lab
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?

[ipet...@gmail.com]

I tried to ping the 10.0.19.1 with two gw and after with one. It didn't work. When I set up the vpn on the netvm it works fine!