Hi
We have the following situation:
A hypervisor using KVM-Qemu/libvirt with a single VM. The VM has the
internal IP 192.168.122.151 on the default network pool using virbr0 on
the hypervisor.
We've set up netfilter rules to DNAT requests on one IP of the
hypervisor to the VM. So, first of all, forwarding to the internal IP
range is allowed:
$IPTABLES -I FORWARD -m state -d 192.168.122.0/24 --state
NEW,RELATED,ESTABLISHED -j ACCEPT
Then we're forwarding a few ports from the hypervisor's public IP to the
VM, imaps being one of them:
Chain PREROUTING (policy ACCEPT 2606 packets, 169K bytes) pkts bytes
target prot opt in out source destination 142 8048 DNAT tcp -- * *
0.0.0.0/0 a.b.c.145 tcp dpt:993 to:192.168.122.151
Since the VM is also doing SMTP, we need it to send out mail via a
dedicated IPv4, which we achieve through the following SNAT rule:
Chain POSTROUTING (policy ACCEPT 1121 packets, 77556 bytes) pkts
bytes target prot opt in out source destination 81 6262 SNAT all -- *
* 192.168.122.151 0.0.0.0/0 to:a.b.c.145
Now, on this mailserver, we're also running a roundcube instance. For
authentication, roundcube connects to the imaps port of the local
dovecot instance. In order for the SSL certificate check to succeed, it
needs to do so using the actual domain name, and cannot use "localhost"
or the loopback IP address.
The problem is that, given the above iptables rules, connecting from
inside the VM to itself via the hypervisor's external interface doesn't
work. The connection simply times out, logging reveals they're not
getting forwarded.
We've added logging to iptables and testing in promisc mode vs. not-promisc:
This is what gets logged when virbr0 is not in promisc mode:
Feb 11 19:12:31 hyper kernel: [199815.004207] prerouting imaps:
IN=virbr0 OUT= PHYSIN=vnet0
MAC=fe:54:00:17:c8:2a:52:54:00:17:c8:2a:08:00 SRC=192.168.122.151
DST=a.b.c.d.145 LEN=60 TOS=0x10 PREC=0x00 TTL=64 ID=40689 DF
PROTO=TCP SPT=43460 DPT=993 WINDOW=29200 RES=0x00 SYN URGP=0
And this when the device is in promisc mode:
Feb 11 19:14:33 hyper kernel: [199937.674189] prerouting imaps:
IN=virbr0 OUT= PHYSIN=vnet0
MAC=fe:54:00:17:c8:2a:52:54:00:17:c8:2a:08:00 SRC=192.168.122.151
DST=a.b.c.d.145 LEN=60 TOS=0x10 PREC=0x00 TTL=64 ID=2244 DF PROTO=TCP
SPT=43461 DPT=993 WINDOW=29200 RES=0x00 SYN URGP=0
Feb 11 19:14:33 hyper kernel: [199937.674221] forwarded imaps: IN=virbr0
OUT=virbr0 PHYSIN=vnet0 MAC=52:54:00:17:c8:2a:52:54:00:17:c8:2a:08:00
SRC=192.168.122.151 DST=192.168.122.151 LEN=60 TOS=0x10 PREC=0x00 TTL=63
ID=2244 DF PROTO=TCP SPT=43461 DPT=993 WINDOW=29200 RES=0x00 SYN URGP=0
Feb 11 19:14:33 hyper kernel: [199937.674766] forwarded imaps: IN=virbr0
OUT=virbr0 PHYSIN=vnet0 MAC=52:54:00:17:c8:2a:52:54:00:17:c8:2a:08:00
SRC=192.168.122.151 DST=192.168.122.151 LEN=52 TOS=0x10 PREC=0x00 TTL=63
ID=2245 DF PROTO=TCP SPT=43461 DPT=993 WINDOW=229 RES=0x00 ACK URGP=0
Another workaround we found is to disable iptables on the bridge
interface.
root@hyper:~# echo 0 >
/proc/sys/net/bridge/bridge-nf-call-iptables
But I do not consider this a solution, merely a workaround. I
do not understand why the forward rule mentioned above does not apply to
the situation where IN and OUT are both virbr0?
Thank you for any advice,
David
--
TenTwentyFour S.à r.l.
W:
www.tentwentyfour.lu
T: +352 20 211 1024
F: +352 20 211 1023
9, avenue des Hauts-Fourneaux
L-4362 Esch/Alzette