How do I configure my RHEL7 server to forward to a VM running on it?

I have a RHEL7 server on which I've created a CentOS7 VM.  I want to be able to ssh and browse to the VM from servers beyond the host.  I presume I use iptables?  Unfortunately I'm poor at iptables so if anyone can assist, that would be great.

All interfaces on host show forwarding enabled, e.g. cat /proc/sys/net/ipv4/conf/em1/forwarding
1

Host ifconfig:
docker0: flags=4099<UP,BROADCAST,MULTICAST>  mtu 1500
        inet 172.17.42.1  netmask 255.255.0.0  broadcast 0.0.0.0
        inet6 fe80::5484:7aff:fefe:9799  prefixlen 64  scopeid 0x20<link>
        ether 56:84:7a:fe:97:99  txqueuelen 0  (Ethernet)
        RX packets 51547  bytes 2812204 (2.6 MiB)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 84869  bytes 109507996 (104.4 MiB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

em1: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
        inet 11.170.107.0  netmask 255.255.248.0  broadcast 11.170.111.255
        inet6 2606:b400:818:61:9a90:96ff:feb9:388e  prefixlen 128  scopeid 0x0<global>
        inet6 2606:b400:818:64:9a90:96ff:feb9:388e  prefixlen 128  scopeid 0x0<global>
        inet6 fe80::9a90:96ff:feb9:388e  prefixlen 64  scopeid 0x20<link>
        ether 98:90:96:b9:38:8e  txqueuelen 1000  (Ethernet)
        RX packets 2479959  bytes 845660135 (806.4 MiB)
        RX errors 2270  dropped 0  overruns 0  frame 2270
        TX packets 660557  bytes 70999354 (67.7 MiB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0
        device interrupt 20  memory 0xf7c00000-f7c20000

lo: flags=73<UP,LOOPBACK,RUNNING>  mtu 65536
        inet 127.0.0.1  netmask 255.0.0.0
        inet6 ::1  prefixlen 128  scopeid 0x10<host>
        loop  txqueuelen 0  (Local Loopback)
        RX packets 84846  bytes 901162181 (859.4 MiB)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 84846  bytes 901162181 (859.4 MiB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

virbr0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
        inet 192.168.122.1  netmask 255.255.255.0  broadcast 192.168.122.255
        ether 52:54:00:b2:a4:ab  txqueuelen 0  (Ethernet)
        RX packets 472957  bytes 27910474 (26.6 MiB)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 613749  bytes 5054836757 (4.7 GiB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

vnet0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
        inet6 fe80::fc54:ff:feee:5516  prefixlen 64  scopeid 0x20<link>
        ether fe:54:00:ee:55:16  txqueuelen 500  (Ethernet)
        RX packets 4240  bytes 636876 (621.9 KiB)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 18175  bytes 270545325 (258.0 MiB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0


VM ifconfig:
br-ex: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
        inet 192.168.122.11  netmask 255.255.255.0  broadcast 192.168.122.255
        inet6 fe80::4cf3:cff:fece:ad43  prefixlen 64  scopeid 0x20<link>
        ether 4e:f3:0c:ce:ad:43  txqueuelen 0  (Ethernet)
        RX packets 580  bytes 53714 (52.4 KiB)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 420  bytes 59379 (57.9 KiB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

eth0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
        inet6 fe80::5054:ff:feee:5516  prefixlen 64  scopeid 0x20<link>
        ether 52:54:00:ee:55:16  txqueuelen 1000  (Ethernet)
        RX packets 744  bytes 62242 (60.7 KiB)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 419  bytes 59381 (57.9 KiB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

lo: flags=73<UP,LOOPBACK,RUNNING>  mtu 65536
        inet 127.0.0.1  netmask 255.0.0.0
        inet6 ::1  prefixlen 128  scopeid 0x10<host>
        loop  txqueuelen 0  (Local Loopback)
        RX packets 28207  bytes 4868317 (4.6 MiB)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 28207  bytes 4868317 (4.6 MiB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0
micktAsked:
Who is Participating?

[Product update] Infrastructure Analysis Tool is now available with Business Accounts.Learn More

x
I wear a lot of hats...

"The solutions and answers provided on Experts Exchange have been extremely helpful to me over the last few years. I wear a lot of hats - Developer, Database Administrator, Help Desk, etc., so I know a lot of things but not a lot about one thing. Experts Exchange gives me answers from people who do know a lot about one thing, in a easy to use platform." -Todd S.

Zephyr ICTCloud ArchitectCommented:
I think you'll need to create a bridge first, before being able to reach the VM's from the LAN, that is, if you want to be able to use the same IP-addressing scheme as from your LAN, this prevents of using things like NAT'ing and stuff...

1- First we'll create a bridge named ‘br0’. In your network-card config (e.g: /etc/sysconfig/network-scripts/ifcfg-em1) add following line and block out the fixed IP for use in the new bridge file.

BRIDGE=br0

Your file would look something like this:
DEVICE="em1"
BRIDGE=br0
ONBOOT="yes"
NM_CONTROLLED="no"
#TYPE=Ethernet
BRIDGE=bridge0
BOOTPROTO=static
#IPADDR=192.168.0.100
#NETMASK=255.255.255.0
#GATEWAY=192.168.0.1

Open in new window


2- Now create /etc/sysconfig/network-scripts/ifcfg-br0 and add:

DEVICE="br0"
BOOTPROTO="static"
ONBOOT="yes"
TYPE="Bridge"
DELAY="0"
IPADDR=192.168.0.100
NETMASK=255.255.255.0

Open in new window


Gateway should go into /etc/sysconfig/network

Something like this:
# Created by anaconda
GATEWAY=192.168.0.1

Open in new window


3- restart the network:
service network restart

Open in new window


4- Make sure that you enabled forwarding:

net.ipv4.ip_forward = 1

Open in new window


Read the file to activate it:

sysctl -p /etc/sysctl.conf

Open in new window


You can also use DHCP for the bridge, just don't enable the IPADDR in the file and replace BOOTPROTO=static with BOOTPROTO=dhcp

Hope that's clear ...
micktAuthor Commented:
The VMs cannot use same network has host.  They'll have to use the existing virbr0 and have addresses on 192.168.122.0.
Zephyr ICTCloud ArchitectCommented:
Might have been usefull to mention this ... Anyway, can you reach your VM from the host where it run on? That should at least work to begin with... If that is not the case, check following:

virsh net-list --all

Open in new window


This should list at least one entry

Make sure forwarding is enabled in the kernel paramaters, something like this:
$ echo "net.ipv4.ip_forward = 1"|sudo tee /etc/sysctl.d/99-ipforward.conf net.ipv4.ip_forward = 1
$ sudo sysctl -p /etc/sysctl.d/99-ipforward.conf net.ipv4.ip_forward = 1

Open in new window

Big Business Goals? Which KPIs Will Help You

The most successful MSPs rely on metrics – known as key performance indicators (KPIs) – for making informed decisions that help their businesses thrive, rather than just survive. This eBook provides an overview of the most important KPIs used by top MSPs.

micktAuthor Commented:
I can ssh to VMs from host and forwarding is enabled.
Zephyr ICTCloud ArchitectCommented:
You will need routing if you want the NAT'ed subnet to be reachable on your network, is virbr0 configured on a separate NIC?
micktAuthor Commented:
Only one NIC.
Zephyr ICTCloud ArchitectCommented:
Could you test if you are able to use ssh with port forwarding to connect to your VM guest from a remote system?

Try this from another machine than your KVM:

ssh root@<ip-of-kvm-host> -L 22:192.168.122.x:22

Open in new window


So you connect via ssh to your KVM host and map local port 22 to the VM port 22 ...
micktAuthor Commented:
ssh root@11.170.107.0 -L 22:192.168.122.11:22
root@11.170.107.0's password:
bind: Address already in use
channel_setup_fwd_listener: cannot listen to port: 22
Could not request local forwarding.
Zephyr ICTCloud ArchitectCommented:
Yeah, that's logical because your KVM host uses that port of course. ... hmmm
Might have to change the ssh port on your VM, if it's just the one VM that's ok, but if you're going to add more VM's in the future ...

That's why a second nic for the bridge would be handy, you can make it a separate network, but, then you'll need routing naturally...

You could try the same command with vnc ports:

ssh root@11.170.107.0 -L 5900:192.168.122.11:5900

Experts Exchange Solution brought to you by

Your issues matter to us.

Facing a tech roadblock? Get the help and guidance you need from experienced professionals who care. Ask your question anytime, anywhere, with no hassle.

Start your 7-day free trial
micktAuthor Commented:
.
It's more than this solution.Get answers and train to solve all your tech problems - anytime, anywhere.Try it for free Edge Out The Competitionfor your dream job with proven skills and certifications.Get started today Stand Outas the employee with proven skills.Start learning today for free Move Your Career Forwardwith certification training in the latest technologies.Start your trial today
Linux Networking

From novice to tech pro — start learning today.