Skip to contentSkip to conversation

ssh into kvm-guests

DISCUSSION brizly vaan van Ulciputz 2 participants 2 messages Jun 9, 2010 – Jun 11, 2010 4 messages not in the archive KVM

lore
Share & tools
lore
#0 lore raw

Hello all,

i don't know why i can not ssh-in into my kvm-guests from another physical machine.

[all my machines/hosts/guests here are Fedora Core 13]
i have a kvm-host, running several bridged guests, and the host itself is a openvpn-server, too.

the kvm-guests can vpn-connect, other clients in my network can vpn-connect.

the kvm-host can ping each kvm-guest,
any network-client (in the same network) can ping the kvm-guests.

BUT i can not ssh-connect into my kvm-guests, neither 'normal' from kvm-host nor from other vpn-clients.
Other vpn-client can connect each-other (open-vpn client-to-client is enabled). And i can ssh-connect from kvm-guests to other normal guests - but this is not the way i need.

i don't know where to look at any more. the kvm-host has a running br0, with correct ip. eth0 is linked to br0. kvm-guests has correct ips set, reaching internet and so on - all good.

only unknown point is that
#brctl show
gives me the information that br0 hast not STP enabled, but virbr0 has (dont understand what STP is good for :-( ).

any ideas where to continue?

_____
Greetings
brizly

A message that is not in the archive (sent off-list or not yet received): [email protected]

A message that is not in the archive (sent off-list or not yet received): 1276204426.1995.7.camel@webClient

A message that is not in the archive (sent off-list or not yet received): [email protected]

A message that is not in the archive (sent off-list or not yet received): 1276267764.2053.19.camel@webClient

#5 lore raw

so, finally, some news:
embarassing, that i didn't check it, but, when i disable iptables in kvm-guest, it works...

interestingly, i set up ssh allows by system-config-firewall, as always in the past (on physically, real machines, none virtual), and it looks al right, ssh is allowed. nevertheless it does not work in my kvm-guests. i will now continue to 'patch' my iptables-rules.

thank you, without your hint with tcpdump and the prohibited-line the fog would never have been lifted for me.

Am Freitag, den 11.06.2010, 16:49 +0200 schrieb brizly vaan van Ulciputz:

Quoted 41 lines

Am Freitag, den 11.06.2010, 10:10 +0300 schrieb Alpár Török :

Quoted 2 lines

What i ment is stopping the VPN server. Completely, just to make sure it isn't interfering

done. that was the easiest part.

Quoted 1 line

tcpdump -i br0 port 22 (or whatever port you have sshd running on)

server is 192.168.23.29
kvm-guest is 192.168.23.108
gateway is 192.168.23.254 (which should not be part of route, here?)

i started dump on server, than tried to "ssh 192.168.23.108", and this is it: http://fpaste.org/Usfs/
(could it paste directly here, but think it's hard to read in here).

Interesting i think is line 7:
IP 192.168.23.108 > 192.168.23.29: ICMP host 192.168.23.108 unreachable
- admin prohibited, length 68

but i don't know how to fix ist. which admin has prohibited what?

Quoted 4 lines

I'm not familiar with openVPN. Does it use one of the bridges ? I will assume it uses tun0 and br0 , and the VM uses vnet0 as a tap since it doesn't have an IP assigned, while tap0 has. Still it's strange that the bridges are on different subnets.

i see just one bridge, br0?
openvpn uses 192.168.24.0, which, i think, is tunX for.
the _real_ network is 192.168.23.0, which is 'linked' to br0 and used by eth0.

Quoted 5 lines

Is this
intentional? Which subnet is the actual _real_ network. If you want your guests on a separate subnet, you need to set the host as GW and enable ip_forward, but it's probably simpler to just bridge them to the real network.

for me it's no matter if the guests are on same physical network or bridged. at the end i want to reach them by another openvpn-network-client (e.g. remote notebook). Nice if the although should be reachable local without vpn, but there is not really a need.

bevore 'installing' the bridge the kvm-guests was on separate network, the default kvm-generated network (in my case, 192.168.122.0), but the effects was the same :-(