1mo ago

VM port forwarding issue with iptables

Here's the setup:

Fedora 41 Server host
Libvirt/QEMU
Alma 9 guest running ssh

My goal is to forward ports from the guest to the host, but change them. I set up a hook(as in the libvirt docs) and it worked on my last server. My hook looks like:

    
#!/bin/bash

if [ "${1}" = "Jellyfin" ]; then

   # Update the following variables to fit your setup
   GUEST_IP=192.168.101.4
   GUEST_PORT=22
   HOST_PORT=2222

   if [ "${2}" = "stopped" ] || [ "${2}" = "reconnect" ]; then
    /sbin/iptables -D FORWARD -o virbr1 -p tcp -d $GUEST_IP --dport $GUEST_PORT -j ACCEPT
    /sbin/iptables -t nat -D PREROUTING -p tcp --dport $HOST_PORT -j DNAT --to $GUEST_IP:$GUEST_PORT
   fi
   if [ "${2}" = "start" ] || [ "${2}" = "reconnect" ]; then
    /sbin/iptables -I FORWARD -o virbr1 -p tcp -d $GUEST_IP --dport $GUEST_PORT -j ACCEPT
    /sbin/iptables -t nat -I PREROUTING -p tcp --dport $HOST_PORT -j DNAT --to $GUEST_IP:$GUEST_PORT
   fi
fi

However, when I ssh to my server:2222, it doesn't work, "Connection refused." I can ssh from inside my server to my guest's ip address, so I know it's not an issue with ssh itself. The guest's iptables rules are:

    
-P INPUT ACCEPT
-P FORWARD ACCEPT
-P OUTPUT ACCEPT

so that's probably not the issue.

My server's iptables rules include:

    
-A FORWARD -d 192.168.101.4/32 -o virbr1 -p tcp -m tcp --dport 22 -j ACCEPT

, so it appears the forwarding happened, but an nmap scan reveals the port is closed:

    
2222/tcp closed EtherNetIP-1

I'm baffled by this issue. Any help would be greatly appreciated!

13 comments

Add or uncomment net.ipv4.ip_forward=1in /etc/sysctl.conf ans then sudo sysctl -p
- sysctl net.ipv4.ip_forward returns:
  
  net.ipv4.ip_forward = 1
  So I'm pretty sure that this is already enabled. Thanks for your answer!
- The one thing I always forget, no matter how many DNAT setups or whatever I write with iptables.

ssh -v can be help troubleshoot connection issues. Any firewalls involved on either end?
- No firewalls on the client, but iptables on host and guest. guest has no rules just allow all, and host rules are listed in the post.
- ssh -v returns:
  
  OpenSSH_9.2p1 Debian-2+deb12u4, OpenSSL 3.0.15 3 Sep 2024 debug1: Reading configuration data /etc/ssh/ssh_config debug1: /etc/ssh/ssh_config line 19: include /etc/ssh/ssh_config.d/*.conf matched no files debug1: /etc/ssh/ssh_config line 21: Applying options for * debug1: Connecting to 192.168.86.73 [192.168.86.73] port 2222. debug1: connect to address 192.168.86.73 port 2222: Connection refused ssh: connect to host 192.168.86.73 port 2222: Connection refused

Your hook has
/sbin/iptables -t nat -I PREROUTING -p tcp --dport $HOST_PORT -j DNAT --to $GUEST_IP:$GUEST_PORT
But I'd didn't think that "--to" was a flag for DNAT, I thought it was "--to-destination"
If you 'iptables -nvL' and 'iptables -t nat -nvL' do you see both your DNAT and forwarding rules (although if the default is ACCEPT and you don't have other rules, the FORWARD one isn't needed), and do you see the packet count for the rules increase?
- From the iptables manpage:
  
  --to offset Set the offset from which it starts looking for any matching. If not passed, default is the packet size. ... --to-destination ipaddr-ipaddr Address range to round-robin over.
  This seems to do something, but the port still appears as closed.
  iptables -nvL returns:
  
  Chain INPUT (policy ACCEPT 0 packets, 0 bytes) pkts bytes target prot opt in out source destination Chain FORWARD (policy ACCEPT 369 packets, 54387 bytes) pkts bytes target prot opt in out source destination 5 300 ACCEPT 6 -- * virbr1 0.0.0.0/0 192.168.101.4 tcp dpt:22 84 6689 ACCEPT 0 -- * br-392a16e9359d 0.0.0.0/0 0.0.0.0/0 ctstate RELATED,ESTABLISHED 7 418 DOCKER 0 -- * br-392a16e9359d 0.0.0.0/0 0.0.0.0/0 146 9410 ACCEPT 0 -- br-392a16e9359d !br-392a16e9359d 0.0.0.0/0 0.0.0.0/0 0 0 ACCEPT 0 -- br-392a16e9359d br-392a16e9359d 0.0.0.0/0 0.0.0.0/0 Chain OUTPUT (policy ACCEPT 0 packets, 0 bytes) pkts bytes target prot opt in out source destination
  I've omitted some listings that were labelled as docker.
  iptables -t nat -nvL returns:
  
  Chain PREROUTING (policy ACCEPT 626 packets, 90758 bytes) pkts bytes target prot opt in out source destination 5 300 DNAT 6 -- * * 0.0.0.0/0 0.0.0.0/0 tcp dpt:2222 to:192.168.101.4:22 Chain INPUT (policy ACCEPT 0 packets, 0 bytes) pkts bytes target prot opt in out source destination Chain OUTPUT (policy ACCEPT 154 packets, 12278 bytes) pkts bytes target prot opt in out source destination 0 0 DOCKER 0 -- * * 0.0.0.0/0 !127.0.0.0/8 ADDRTYPE match dst-type LOCAL Chain POSTROUTING (policy ACCEPT 290 packets, 22404 bytes) pkts bytes target prot opt in out source destination 0 0 MASQUERADE 0 -- * !br-392a16e9359d 172.18.0.0/16 0.0.0.0/0
  I've also omitted some listings that were labelled as docker.
  After running the ssh command, the bytes seem to increase. After 1 ssh attempt:
  
  7 420 DNAT 6 -- * * 0.0.0.0/0 0.0.0.0/0 tcp dpt:2222 to:192.168.101.4:22
  After another ssh attempt:
  
  8 480 DNAT 6 -- * * 0.0.0.0/0 0.0.0.0/0 tcp dpt:2222 to:192.168.101.4:22
  
  For general awareness, not all flags can match all parts of an iptables command; the part you included there with "--to offset" is only valid with the string module, and not the DNAT action. That said after playing around with it a little, iptables actually does short flag matching, so 'DNAT --to 1.2.3.4' 'DNAT --to-d 1.2.3.4' and 'DNAT --to-destination' are all equivalent, so not the source of your issue.
  I am having trouble following the IP scheme, though. Is your Alma guest 192.168.101.4, or is that the host IP? If it's Alma's and you are attempting to ssh from that IP to the host with that iptables rule, what should happen is that DNAT would then redirect that connection back to Alma. If the guest doesn't have a :22 listener, you'd get a connection refused from itself.

13 comments