Project Alpha
The home of Project Equinox

Connection Established


Posts in This forum
Oliver said on 11:37:31 08-Sep-2016

Don't worry if you don't understand this, I wrote it predominantly for my own reminder as I keep doing shit, breaking it and then forgetting how I made it work in the first damn place!

I'm trying to connect my QEMU VM machine, accessible through Virsh and so forth to the internet. This isn't hard as this is done for me anyway. I set up a VM Host which is connected to a network that works with the internet and have a network interface on the VM, everything seems to work there

To prove this, I'm gonna slap myself into the VM via the management console of my choice (which is Virtual Machine Manager at this moment. I want to use Archipel but it's being a dick. If you work for Archipel or have ever got it working, get in touch! I wanna bash your head in for information of why the hell it looks so cool but is a bitch to set up! :<!!) and running both a ping and an ifconfig

Well my ping to google out the box works swell and my ifconfig shows me exactly what I need to see: an lo interface which we don't really care about as it's only function is to make the base crap work and this weird one that replaces eth0 called ens3 for some reason best known to itself. (I could rename it, but arsed? No!) This shows me an IP of

If I sit on, which incidentally is also on my network, I can access the ssh console. That means internal routing is working. But what if I'm sitting on Connection refused.

Now you can get several different responses here. "No route to host" being one if your computer has no idea how to get from where you are to where it is, but in this case "Connection refused" makes it sound like it IS getting where it needs to; but this can't be as we've just done an ssh on that machine and the connection was accepted... so either a connection is being refused by another means we don't know about (something not supported by the logs at this point) or the connection is being routed elsewhere and the system's not being informed... well a shutting down of the VM and an ssh getting the same response proves that latter.

So let's put into perspective what's going on here. The VM wants to access the internet. The VM contacts the VM host and the VM host talks to the Internet host on our behalf. Then the Internet host talks to the internet on the VM's behalf until a response is returned, then the internet host returns it to the VM host an the VM host returns it to the client machine. That all seems to work right out the box.

But the system is not set up to do the other hanky-panky of wanting to be able to connect the network there through routing without using the internet, which is a pain because that box isn't internet facing... let's do some routing!

I'm on My default gateway is the internet host at I suppose I could set up a secondary DNS host on and do things that way, but will it work and what's the point? Well I tried it anyway and dick all seems to happen: the connection is still refused, but is this because the VM is powered down? Nope.

Ok so THAT thought aside, I need to tell the default gateway ( where to go (cause that's where I go) when a request comes through. Let's take a look at what we have on the internet host

Well route gives me the impression that is routing to (Using the command 'route add -net gw dev eth1') meaning that anything coming into the system on eth1 ( for is routed directly to Seems good and what I want :)

My next port of call is for iptables, which seems to be handling routing for other machines, so let's try adding a few things in here

iptables -A FORWARD -i eth1 -o -eth1 -s -d -j ACCEPT

So anything that comes in on eth1 for 192.168.124.* is accepted and moved to using the eth1 interface all the time. This hasn't helped as I'm still getting connection refuseds on the command line. But I'm now pretty convinced the internet host is overcompensating for what is needed to be going on. Since I can connect to as from both and, I think I'm safe to assume that SOME address resolution is being enacted by the inernet server. So let's stop worring about that Let's check the VM host

The VM host has a similar route (This time it's route add -net dev virbr0) so EVERYTHING from EVERYWHERE from coming into that machine is handled by our virtual bridge. I don't see how this can harm, but doesn't really seem to be helping. I've also never seen it before so I may try removing it later =^.^=

Let's check the iptables as I think this is where things are falling over. I have a clusterfuck of interfaces on the VM host but since none are conflicting, I'm going to ignore those for a while, so let's see if the following will help

iptables -A FORWARD -i eth0 -o -virbr0 -d -j ACCEPT

This will state that anything from anywhere on eth0 destined for 192.168.124.* on virbr0 will be accepted

The connection is still being refused, but as I can see some reject lines sneaking into my iptables configurations, I'm going to blast those out. In this case the lines are 4 and 5 so I'll just run "iptables -D FORWARD 4" twice to remove those.

Yes! That hit the nail on the head! I can access from So can I do it from Fuck to the yes :D

So a top tip: If you're getting "Connection refused"s when you think you ought not to be, check for REJECT lines in your forward chains, particularly if they are "anywhere to anywhere"s with a "reject-with icmp-port-unreachable" clause!


Information will appear here


Information will appear here


+44 (0) 7535 692215
Project Alpha The home of Project Equinox