Qubes R2RC1 - can "traceroute --tcp" between VMs but not "telnet"

[Frank Schäckermann]

Hi!

I have gotten networking setup between two VMs by adding the necessary IPTABLES rules according to the wiki. And as you can see below, "traceroute --tcp" works in both directions, telnet to port 1414 on the local VM works as well, but telnet from the remote VM ends with "No route to Host". Does anybody have an Idea, what is going on here?

Output from the VM where the port 1414 is open (local VM):

-------------------------------------------------------------
[user@local ~]$ ifconfig eth0
eth0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
        inet 10.137.2.3  netmask 255.255.255.255  broadcast 10.255.255.255
        inet6 fe80::216:3eff:fe5e:6c01  prefixlen 64  scopeid 0x20<link>
        ether 00:16:3e:5e:6c:01  txqueuelen 1000  (Ethernet)
        RX packets 8  bytes 536 (536.0 B)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 8  bytes 648 (648.0 B)

        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0
[user@local ~]$ sudo traceroute --tcp 10.137.2.11
traceroute to 10.137.2.11 (10.137.2.11), 30 hops max, 60 byte packets
 1  10.137.2.1 (10.137.2.1)  0.683 ms  0.612 ms  0.587 ms
 2  10.137.2.11 (10.137.2.11)  1.206 ms !X  1.188 ms !X  1.148 ms !X
[user@local ~]$ telnet 10.137.2.3 1414
Trying 10.137.2.3...
Connected to 10.137.2.3.
Escape character is '^]'.
^]
telnet> quit
Connection closed.
-------------------------------------------------------------

Output from the remote VM:

-------------------------------------------------------------
[user@Development ~]$ ifconfig eth0
eth0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
        inet 10.137.2.11  netmask 255.255.255.255  broadcast 10.255.255.255
        inet6 fe80::216:3eff:fe5e:6c09  prefixlen 64  scopeid 0x20<link>
        ether 00:16:3e:5e:6c:09  txqueuelen 1000  (Ethernet)
        RX packets 8  bytes 536 (536.0 B)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 8  bytes 648 (648.0 B)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0
[user@Development ~]$ sudo traceroute --tcp 10.137.2.3
traceroute to 10.137.2.3 (10.137.2.3), 30 hops max, 60 byte packets
 1  10.137.2.1 (10.137.2.1)  0.294 ms  0.210 ms  0.167 ms
 2  10.137.2.3 (10.137.2.3)  0.350 ms !X  0.343 ms !X  0.332 ms !X
[user@Development ~]$ telnet 10.137.2.3 1414
Trying 10.137.2.3...
telnet: connect to address 10.137.2.3: No route to host
[user@Development ~]$
-------------------------------------------------------------

The system was upgraded from a (at that time) up-to-date Qubes R2B3 install and all current updates have been applied.

Any help would be much appreciated!

Regards, Frank

[Marek Marczykowski-Górecki]

"!X" means "communication administratively prohibited"

--
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?

[Frank Schäckermann]

Oh weil... yet another dumb question asked and answered. ;-) At least I know now that neither traceroute nor telnet actually work.

But the question remains: why? I have followed the wiki and added the firewall rules

-I FORWARD -s 10.137.2.3 -d 10.137.2.11 -j ACCEPT
-I FORWARD -s 10.137.2.11 -d 10.137.2.3 -j ACCEPT

to allow traffic between the two VMs and the ping is actually working.
Therefore the icmp protocol is routed okay but tcp obviously isn't.
I have been playing around with iptables commands trying this and that,
but I must be missing something (hopefully not too) obvious.

Attached is the current output of iptables-save of the firewallvm.

Frank

[Marek Marczykowski-Górecki]

There is also firewall in AppVM itself, which by default block all incoming
connections (but allow icmp).

[Frank Schäckermann]

Okay... I missed the BLEEDING obvious... *blushing*

Adding

-I INPUT 3 -p tcp -m tcp --dport 1414 -j ACCEPT

in local VM did the trick. Thanks for your patience, Marek!

Regards, Frank