PVE-Firewall Host vs. VM

andy77

Renowned Member
Jul 6, 2016
248
13
83
41
Hello @all,

I am trying now to understand the firewall configuration for a while but do not really get it working like I want. Maybe someone has a hint for me because I am getting a bit frustrated, not finding a solution for a long time. :(

So first here is my network config that I am using at Hetzner. I have one "main" and two "additional" IPs from them. The additional IPs are routed through the main IP. I use vmbr0 for them.

Code:
auto lo
iface lo inet loopback
#iface lo inet6 loopback

# device: eth0
auto  eth0
iface eth0 inet static
  address  130.x.y.145
  netmask  255.255.255.255
  gateway  130.x.y.129
  pointopoint  130.x.y.129
  # default route to access subnet
  #up route add -net 130.x.y.128 netmask 255.255.255.192 gw 130.x.y.129 eth0

auto vmbr0
iface vmbr0 inet static
  address  130.x.y.145
  netmask  255.255.255.255
  bridge_ports none
  bridge_stp off
  bridge_fd 0

  # Public subnet block
  up ip route add 130.x.y.184/32 dev vmbr0
  up ip route add 130.x.y.189/32 dev vmbr0


# Internal Network
auto vmbr1
iface vmbr1 inet static
  address 10.0.0.1/23
  bridge_ports dummy0
  bridge_stp off
  bridge_fd 0


Now I have two Windows VMs running on that host that has the additional IPs 130.x.x.184 and 130.x.y.189 assigned. I have access to the Internet and everything seems to work great.

Now lets go to my Firewall config cluster.fw :

Code:
[OPTIONS]

enable: 1
policy_in: DROP

[IPSET external_access]

x.y.z.17 # server1
x.y.z.18 # server2
x.y.z.68 # server3
x.x.0.0/15 # myprovidersubnet

[IPSET proxmox_nodes]

130.x.y.145 # host1
130.x.y.148 # host2
130.x.y.132 # host3
130.x.y.195 # host4

[RULES]

IN ACCEPT -i vmbr1
IN ACCEPT -i eth0 -source +proxmox_nodes -p udp -dport 655 # Allow all nodes to establish VPN connection
IN ACCEPT -i eth0 -source +proxmox_nodes -p tcp -dport 655 # Allow all nodes to establish VPN connection
IN ACCEPT -i eth0 -source +external_access -p tcp -dport 8006 # Allow certain IPs to Proxmox Webinterface on eth0
IN ACCEPT -i eth0 -p tcp -dport 22 # Allow all IPs to SSH on eth0

[group windowsservers]

and the config vm.fw :

Code:
[OPTIONS]

enable: 1

[RULES]

IN RDP(ACCEPT) -source +external_access


As I understand with this setup the VM should be accessable through RDP. But this is not the case.
Then I though, ok maybe it is because of the Hetzner network config, because everything is routed through the main IP (host IP).

So I also have tried to change the vm.fw to following:

Code:
[OPTIONS]

enable: 1

[RULES]

IN RDP(ACCEPT) -source +proxmox_nodes

With this config the RDP connection worked well.

But something is weered: In cluster.fw I did not allowed no access to RDP. Only on vm.fw I said that the host can access RDP. Why do I now have access via RDP to that VM even if I am not in one of the specified "ACCEPT" IP addresses? (public IP form a different provider)
It seems that with this config public has access to that VM via RDP.

Now the questino is why ?o_O

And what would be the correct way to go for that project.

Thx very very much for any help.

Regards
Andy
 
Hi Andy
The behaviour you see is normal, as the rules you define for at the VM level will override the rules set at the data center level.
The idea is that you can block everything at the datacenter or node level, and then fine-grain allow traffic on each VM.
 
Hello Manu,

thx for your answer.

Well this is exactly the config that we try to achieve.

- on cluster level
"enable firewall = yes"
"input policy = drop"
"few rules but noting for RDP"

- on node level
"enable firewall = yes"
"no rules"

- on VM level
"enable firewall = yes"
"input policy = drop"
"rule: in accept RDP mypublicIP"


When configuring it like that I can't connect to the VM over RDP.

But when I set in the VMs accept RDP rule the IP of the node the VM is running on, then I can connect to the VM from my public isp IP (that is totally different then the IP of the node).

So this is the point that I do not understand.


Thx a lot

Regards
Andy
 
Could you please post the configuration of your two VMs ?
( qm config my_vmid)
 
Code:
bootdisk: virtio0
cores: 8
keyboard: de
memory: 51200
name: server1
net0: virtio=2E:38:7C:E2:77:A9,bridge=vmbr0,firewall=1
net1: virtio=B2:3C:11:51:BE:08,bridge=vmbr1
numa: 0
ostype: win8
smbios1: uuid=256a7454-1b49-45af-a7d3-081947c1cd13
sockets: 1
virtio0: local:105/vm-105-disk-3.raw,size=100G
virtio1: local:105/vm-105-disk-1.raw,backup=0,size=360G
virtio2: nfsb1px:105/vm-105-disk-1.qcow2,backup=0,size=100G
virtio3: local:105/vm-105-disk-2.raw,size=10G
 
Last edited:
One thing I noted in your setting is that you configured both eth0 and vmbr0 to have the IP adress
130.x.y.145.
Since you want to use a routing setting, you should not need to add the IP adress to vmbr0.

Also where did you configure IP forwarding for your routing setup ? Usually people do configure IP forwarding with
post-up echo 1 > /proc/sys/net/ipv4/ip_forward in /etc/network/interfaces but I can't see it here.

> But when I set in the VMs accept RDP rule the IP of the node the VM is running on, then I can connect to the VM from my public isp IP (that is totally different then the IP of the node).

The only case where I could think that you need to add the IP of the node as allowed in the firewall of the guest would be the case where you use reverse NAT, so in that case the incoming IP packets would appear as coming from the pve host and not from another internet IP.
 
One thing I noted in your setting is that you configured both eth0 and vmbr0 to have the IP adress
130.x.y.145.
Since you want to use a routing setting, you should not need to add the IP adress to vmbr0.

Well this is because of Hetzners Netowrk configuration. They sugesst in their WIKI to do so:
https://wiki.hetzner.de/index.php/Proxmox_VE#Netzwerkkonfiguration_Hostsystem_KVM.2FRouted

Also where did you configure IP forwarding for your routing setup ? Usually people do configure IP forwarding with
post-up echo 1 > /proc/sys/net/ipv4/ip_forward in /etc/network/interfaces but I can't see it here.

As you can see here, ipv4 forwarding is active on the node:
Code:
root@node1 /# sysctl net.ipv4.ip_forward
net.ipv4.ip_forward = 1
 
The only case where I could think that you need to add the IP of the node as allowed in the firewall of the guest would be the case where you use reverse NAT, so in that case the incoming IP packets would appear as coming from the pve host and not from another internet IP.

But as you can see the VM is configured to use the vmbr0 and no nat.
 
Well, when I connect through RDP to the VM, I can see at TCP connections as "remote address" the node IP instead of my public-ISP-IP. So it seems really that there is some kind of reverse nat.

But now the question is why?
 
I reproduced your setup here ( routed point to point link ) and the IP packets in the node are properly displayed as coming from the public ISP adress. So I cannot reproduce the issue you're mentionning.

At that point it would be useful to get the output of tcpdump as run on the vm
( use tcpdump -D to get a list of interfaces for the parameter -i)

tcpdump -i 1 dst 130.x.y.184 and port 3389

Are you sure you're connecting directly to the punblic IP adress of your VM and not via some kind of VPN ?
 
Should I run it on node or VM?

you can try on both, separately

what is important is selecting the right interface where the packets are running though ( -i flag )

also for debuggin purpose pelase privide the ouput of iptables-save on the host
 
Well I have only one physical nic so all should be passed through eth0 or vmbr0 (the public ip bridge).

Running whoer.net on the VM tells me that I have the correct public IP (138.x.y.189).

On node tcpdump is telling me the following
Code:
16:57:09.781871 IP static.189.x.y.138.clients.your-server.de.3389 > 178.112.x.x.wireless.dyn.drei.com.43012: Flags [P.], seq 101:202, ack 1, win 63303, length 101
16:57:09.899547 IP static.145.y.x.138.clients.your-server.de.43012 > static.189.x.y.138.clients.your-server.de.3389: Flags [.], ack 102, win 909, length 0
16:57:10.797434 IP static.189.x.y.138.clients.your-server.de.3389 > 178.112.x.x.wireless.dyn.drei.com.43012: Flags [P.], seq 202:303, ack 1, win 63303, length 101
16:57:10.904164 IP static.145.y.x.138.clients.your-server.de.43012 > static.189.x.y.138.clients.your-server.de.3389: Flags [.], ack 203, win 908, length 0
16:57:11.797445 IP static.189.x.y.138.clients.your-server.de.3389 > 178.112.x.x.wireless.dyn.drei.com.43012: Flags [P.], seq 303:404, ack 1, win 63303, length 101
16:57:11.916864 IP static.145.y.x.138.clients.your-server.de.43012 > static.189.x.y.138.clients.your-server.de.3389: Flags [.], ack 304, win 908, length 0
16:57:12.797478 IP static.189.x.y.138.clients.your-server.de.3389 > 178.112.x.x.wireless.dyn.drei.com.43012: Flags [P.], seq 404:505, ack 1, win 63303, length 101
16:57:13.109851 IP static.189.x.y.138.clients.your-server.de.3389 > 178.112.x.x.wireless.dyn.drei.com.43012: Flags [P.], seq 404:505, ack 1, win 63303, length 101
16:57:13.176950 IP static.145.y.x.138.clients.your-server.de.43012 > static.189.x.y.138.clients.your-server.de.3389: Flags [.], ack 405, win 908, options [nop,nop,sack 1 {304:405}], length 0
16:57:13.813102 IP static.189.x.y.138.clients.your-server.de.3389 > 178.112.x.x.wireless.dyn.drei.com.43012: Flags [P.], seq 505:606, ack 1, win 63303, length 101
16:57:14.144159 IP static.145.y.x.138.clients.your-server.de.43012 > static.189.x.y.138.clients.your-server.de.3389: Flags [.], ack 506, win 907, length 0
16:57:14.828602 IP static.189.x.y.138.clients.your-server.de.3389 > 178.112.x.x.wireless.dyn.drei.com.43012: Flags [P.], seq 606:707, ack 1, win 63303, length 101
16:57:14.943953 IP static.145.y.x.138.clients.your-server.de.43012 > static.189.x.y.138.clients.your-server.de.3389: Flags [.], ack 607, win 907, length 0
 
And here the iptables-save output

Code:
# Generated by iptables-save v1.4.21 on Tue Aug 30 17:10:12 2016
*nat
:PREROUTING ACCEPT [5301:388580]
:INPUT ACCEPT [678:42672]
:OUTPUT ACCEPT [2403:172231]
:POSTROUTING ACCEPT [5814:420336]
-A POSTROUTING -o vmbr0 -j MASQUERADE
COMMIT
# Completed on Tue Aug 30 17:10:12 2016
# Generated by iptables-save v1.4.21 on Tue Aug 30 17:10:12 2016
*filter
:INPUT ACCEPT [165379:35899110]
:FORWARD ACCEPT [23871:16513866]
:OUTPUT ACCEPT [161912:27787634]
:PVEFW-Drop - [0:0]
:PVEFW-DropBroadcast - [0:0]
:PVEFW-FORWARD - [0:0]
:PVEFW-FWBR-IN - [0:0]
:PVEFW-FWBR-OUT - [0:0]
:PVEFW-HOST-IN - [0:0]
:PVEFW-HOST-OUT - [0:0]
:PVEFW-INPUT - [0:0]
:PVEFW-OUTPUT - [0:0]
:PVEFW-Reject - [0:0]
:PVEFW-SET-ACCEPT-MARK - [0:0]
:PVEFW-logflags - [0:0]
:PVEFW-reject - [0:0]
:PVEFW-smurflog - [0:0]
:PVEFW-smurfs - [0:0]
:PVEFW-tcpflags - [0:0]
:fail2ban-proxmox - [0:0]
:fail2ban-ssh - [0:0]
:tap102i0-IN - [0:0]
:tap102i0-OUT - [0:0]
:tap105i0-IN - [0:0]
:tap105i0-OUT - [0:0]
-A INPUT -p tcp -m multiport --dports 443,80,8006 -j fail2ban-proxmox
-A INPUT -p tcp -m multiport --dports 22 -j fail2ban-ssh
-A INPUT -j PVEFW-INPUT
-A FORWARD -j PVEFW-FORWARD
-A OUTPUT -j PVEFW-OUTPUT
-A PVEFW-Drop -p tcp -m tcp --dport 43 -j PVEFW-reject
-A PVEFW-Drop -j PVEFW-DropBroadcast
-A PVEFW-Drop -p icmp -m icmp --icmp-type 3/4 -j ACCEPT
-A PVEFW-Drop -p icmp -m icmp --icmp-type 11 -j ACCEPT
-A PVEFW-Drop -m conntrack --ctstate INVALID -j DROP
-A PVEFW-Drop -p udp -m multiport --dports 135,445 -j DROP
-A PVEFW-Drop -p udp -m udp --dport 137:139 -j DROP
-A PVEFW-Drop -p udp -m udp --sport 137 --dport 1024:65535 -j DROP
-A PVEFW-Drop -p tcp -m multiport --dports 135,139,445 -j DROP
-A PVEFW-Drop -p udp -m udp --dport 1900 -j DROP
-A PVEFW-Drop -p tcp -m tcp ! --tcp-flags FIN,SYN,RST,ACK SYN -j DROP
-A PVEFW-Drop -p udp -m udp --sport 53 -j DROP
-A PVEFW-Drop -m comment --comment "PVESIG:zfGV4KTPaxGVOCwRUVqqqbR0IhM"
-A PVEFW-DropBroadcast -m addrtype --dst-type BROADCAST -j DROP
-A PVEFW-DropBroadcast -m addrtype --dst-type MULTICAST -j DROP
-A PVEFW-DropBroadcast -m addrtype --dst-type ANYCAST -j DROP
-A PVEFW-DropBroadcast -d 224.0.0.0/4 -j DROP
-A PVEFW-DropBroadcast -m comment --comment "PVESIG:NyjHNAtFbkH7WGLamPpdVnxHy4w"
-A PVEFW-FORWARD -m conntrack --ctstate INVALID -j DROP
-A PVEFW-FORWARD -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT
-A PVEFW-FORWARD -m physdev --physdev-in fwln+ --physdev-is-bridged -j PVEFW-FWBR-IN
-A PVEFW-FORWARD -m physdev --physdev-out fwln+ --physdev-is-bridged -j PVEFW-FWBR-OUT
-A PVEFW-FORWARD -m comment --comment "PVESIG:qnNexOcGa+y+jebd4dAUqFSp5nw"
-A PVEFW-FWBR-IN -m conntrack --ctstate INVALID,NEW -j PVEFW-smurfs
-A PVEFW-FWBR-IN -m physdev --physdev-out tap102i0 --physdev-is-bridged -j tap102i0-IN
-A PVEFW-FWBR-IN -m physdev --physdev-out tap105i0 --physdev-is-bridged -j tap105i0-IN
-A PVEFW-FWBR-IN -m comment --comment "PVESIG:30r4tu+yJA3q/vYDP7ktTlkmT9w"
-A PVEFW-FWBR-OUT -m physdev --physdev-in tap102i0 --physdev-is-bridged -j tap102i0-OUT
-A PVEFW-FWBR-OUT -m physdev --physdev-in tap105i0 --physdev-is-bridged -j tap105i0-OUT
-A PVEFW-FWBR-OUT -m comment --comment "PVESIG:y0EPXue8ALDu4JHA7sOMM2FwUCo"
-A PVEFW-HOST-IN -i lo -j ACCEPT
-A PVEFW-HOST-IN -m conntrack --ctstate INVALID -j DROP
-A PVEFW-HOST-IN -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT
-A PVEFW-HOST-IN -m conntrack --ctstate INVALID,NEW -j PVEFW-smurfs
-A PVEFW-HOST-IN -p igmp -j RETURN
-A PVEFW-HOST-IN -i vmbr1 -j RETURN
-A PVEFW-HOST-IN -i eth0 -p udp -m set --match-set PVEFW-0-proxmox_nodes-v4 src -m udp --dport 655 -j RETURN
-A PVEFW-HOST-IN -i eth0 -p tcp -m set --match-set PVEFW-0-proxmox_nodes-v4 src -m tcp --dport 655 -j RETURN
-A PVEFW-HOST-IN -i eth0 -p tcp -m set --match-set PVEFW-0-external_access-v4 src -m tcp --dport 8006 -j RETURN
-A PVEFW-HOST-IN -i eth0 -p tcp -m tcp --dport 22 -j RETURN
-A PVEFW-HOST-IN -p tcp -m set --match-set PVEFW-0-management-v4 src -m tcp --dport 8006 -j RETURN
-A PVEFW-HOST-IN -p tcp -m set --match-set PVEFW-0-management-v4 src -m tcp --dport 5900:5999 -j RETURN
-A PVEFW-HOST-IN -p tcp -m set --match-set PVEFW-0-management-v4 src -m tcp --dport 3128 -j RETURN
-A PVEFW-HOST-IN -p tcp -m set --match-set PVEFW-0-management-v4 src -m tcp --dport 22 -j RETURN
-A PVEFW-HOST-IN -s 10.0.0.0/23 -d 10.0.0.0/23 -p udp -m udp --dport 5404:5405 -j RETURN
-A PVEFW-HOST-IN -s 10.0.0.0/23 -p udp -m addrtype --dst-type MULTICAST -m udp --dport 5404:5405 -j RETURN
-A PVEFW-HOST-IN -j PVEFW-Drop
-A PVEFW-HOST-IN -j DROP
-A PVEFW-HOST-IN -m comment --comment "PVESIG:DhtAKGxt0gmPNVlorLPIb3W6xfE"
-A PVEFW-HOST-OUT -o lo -j ACCEPT
-A PVEFW-HOST-OUT -m conntrack --ctstate INVALID -j DROP
-A PVEFW-HOST-OUT -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT
-A PVEFW-HOST-OUT -p igmp -j RETURN
-A PVEFW-HOST-OUT -d 10.0.0.0/23 -p tcp -m tcp --dport 8006 -j RETURN
-A PVEFW-HOST-OUT -d 10.0.0.0/23 -p tcp -m tcp --dport 22 -j RETURN
-A PVEFW-HOST-OUT -d 10.0.0.0/23 -p tcp -m tcp --dport 5900:5999 -j RETURN
-A PVEFW-HOST-OUT -d 10.0.0.0/23 -p tcp -m tcp --dport 3128 -j RETURN
-A PVEFW-HOST-OUT -d 10.0.0.0/23 -p udp -m udp --dport 5404:5405 -j RETURN
-A PVEFW-HOST-OUT -p udp -m addrtype --dst-type MULTICAST -m udp --dport 5404:5405 -j RETURN
-A PVEFW-HOST-OUT -j RETURN
-A PVEFW-HOST-OUT -m comment --comment "PVESIG:ERKDaVoC9edl9FZ+Ed/FFoYd+P0"
-A PVEFW-INPUT -j PVEFW-HOST-IN
-A PVEFW-INPUT -m comment --comment "PVESIG:+5iMmLaxKXynOB/+5xibfx7WhFk"
-A PVEFW-OUTPUT -j PVEFW-HOST-OUT
-A PVEFW-OUTPUT -m comment --comment "PVESIG:LjHoZeSSiWAG3+2ZAyL/xuEehd0"
-A PVEFW-Reject -p tcp -m tcp --dport 43 -j PVEFW-reject
-A PVEFW-Reject -j PVEFW-DropBroadcast
-A PVEFW-Reject -p icmp -m icmp --icmp-type 3/4 -j ACCEPT
-A PVEFW-Reject -p icmp -m icmp --icmp-type 11 -j ACCEPT
-A PVEFW-Reject -m conntrack --ctstate INVALID -j DROP
-A PVEFW-Reject -p udp -m multiport --dports 135,445 -j PVEFW-reject
-A PVEFW-Reject -p udp -m udp --dport 137:139 -j PVEFW-reject
-A PVEFW-Reject -p udp -m udp --sport 137 --dport 1024:65535 -j PVEFW-reject
-A PVEFW-Reject -p tcp -m multiport --dports 135,139,445 -j PVEFW-reject
-A PVEFW-Reject -p udp -m udp --dport 1900 -j DROP
-A PVEFW-Reject -p tcp -m tcp ! --tcp-flags FIN,SYN,RST,ACK SYN -j DROP
-A PVEFW-Reject -p udp -m udp --sport 53 -j DROP
-A PVEFW-Reject -m comment --comment "PVESIG:3gYHaSHlZx5luiKyM0oCsTVaXi4"
-A PVEFW-SET-ACCEPT-MARK -j MARK --set-xmark 0x80000000/0x80000000
-A PVEFW-SET-ACCEPT-MARK -m comment --comment "PVESIG:K9jRaFw5I2si1xj1eGi18ZF/Ng0"
-A PVEFW-logflags -j DROP
-A PVEFW-logflags -m comment --comment "PVESIG:ewllejV/lK5Rjmt/E3xIODQgfYg"
-A PVEFW-reject -m addrtype --dst-type BROADCAST -j DROP
-A PVEFW-reject -s 224.0.0.0/4 -j DROP
-A PVEFW-reject -p icmp -j DROP
-A PVEFW-reject -p tcp -j REJECT --reject-with tcp-reset
-A PVEFW-reject -p udp -j REJECT --reject-with icmp-port-unreachable
-A PVEFW-reject -p icmp -j REJECT --reject-with icmp-host-unreachable
-A PVEFW-reject -j REJECT --reject-with icmp-host-prohibited
-A PVEFW-reject -m comment --comment "PVESIG:KM/fOv4KvGn8XvMqxoiRCdvlji8"
-A PVEFW-smurflog -j DROP
-A PVEFW-smurflog -m comment --comment "PVESIG:k8rhuGB1IUidugKwAufSGGgKAZ4"
-A PVEFW-smurfs -s 0.0.0.0/32 -j RETURN
-A PVEFW-smurfs -m addrtype --src-type BROADCAST -g PVEFW-smurflog
-A PVEFW-smurfs -s 224.0.0.0/4 -g PVEFW-smurflog
-A PVEFW-smurfs -m comment --comment "PVESIG:HssVe5QCBXd5mc9kC88749+7fag"
-A PVEFW-tcpflags -p tcp -m tcp --tcp-flags FIN,SYN,RST,PSH,ACK,URG FIN,PSH,URG -g PVEFW-logflags
-A PVEFW-tcpflags -p tcp -m tcp --tcp-flags FIN,SYN,RST,PSH,ACK,URG NONE -g PVEFW-logflags
-A PVEFW-tcpflags -p tcp -m tcp --tcp-flags SYN,RST SYN,RST -g PVEFW-logflags
-A PVEFW-tcpflags -p tcp -m tcp --tcp-flags FIN,SYN FIN,SYN -g PVEFW-logflags
-A PVEFW-tcpflags -p tcp -m tcp --sport 0 --tcp-flags FIN,SYN,RST,ACK SYN -g PVEFW-logflags
-A PVEFW-tcpflags -m comment --comment "PVESIG:CMFojwNPqllyqD67NeI5m+bP5mo"
-A fail2ban-proxmox -j RETURN
-A fail2ban-ssh -j RETURN
-A tap102i0-IN -p udp -m udp --sport 67 --dport 68 -j ACCEPT
-A tap102i0-IN -j PVEFW-Drop
-A tap102i0-IN -j DROP
-A tap102i0-IN -m comment --comment "PVESIG:YcDElIN39njdXQzPP0qPJyINvgk"
-A tap102i0-OUT -p udp -m udp --sport 68 --dport 67 -g PVEFW-SET-ACCEPT-MARK
-A tap102i0-OUT -m mac ! --mac-source 26:F7:97:FD:83:BA -j DROP
-A tap102i0-OUT -j MARK --set-xmark 0x0/0x80000000
-A tap102i0-OUT -g PVEFW-SET-ACCEPT-MARK
-A tap102i0-OUT -m comment --comment "PVESIG:sOrSFBITmSfPMcjdovTeRMWoF/U"
-A tap105i0-IN -p udp -m udp --sport 67 --dport 68 -j ACCEPT
-A tap105i0-IN -s 138.x.y.145/32 -p tcp -m tcp --dport 21 -j ACCEPT
-A tap105i0-IN -s 138.x.y.145/32 -p tcp -m tcp --dport 80 -j ACCEPT
-A tap105i0-IN -s 138.x.y.145/32 -p tcp -m tcp --dport 443 -j ACCEPT
-A tap105i0-IN -s 138.x.y.145/32 -p tcp -m tcp --dport 3389 -j ACCEPT
-A tap105i0-IN -j PVEFW-Drop
-A tap105i0-IN -j DROP
-A tap105i0-IN -m comment --comment "PVESIG:wJotfddJGFVOSr4DN9UwDIb8Hqc"
-A tap105i0-OUT -p udp -m udp --sport 68 --dport 67 -g PVEFW-SET-ACCEPT-MARK
-A tap105i0-OUT -m mac ! --mac-source 2E:38:7C:E2:77:A9 -j DROP
-A tap105i0-OUT -j MARK --set-xmark 0x0/0x80000000
-A tap105i0-OUT -g PVEFW-SET-ACCEPT-MARK
-A tap105i0-OUT -m comment --comment "PVESIG:45/vJ2GxGU10aOrQ1dSDcnER7xY"
COMMIT
 
And here the tcpdump form VM

Code:
17:18:37.863250 IP static.189.y.x.138.clients.your-server.de.3389 > static.145.y.x.138.clients.your-server.de.1024: P 2784670514:2784671159(645) ack 125660644 win 62661
17:18:37.878885 IP static.145.y.x.138.clients.your-server.de.1024 > static.189.y.x.138.clients.your-server.de.3389: P 1:86(85) ack 4294966059 win 905
17:18:37.908691 IP static.145.y.x.138.clients.your-server.de.1024 > static.189.y.x.138.clients.your-server.de.3389: . ack 645 win 909
17:18:37.923773 IP static.189.y.x.138.clients.your-server.de.3389 > static.145.y.x.138.clients.your-server.de.1024: . ack 86 win 64000
17:18:38.924763 IP static.189.y.x.138.clients.your-server.de.3389 > static.145.y.x.138.clients.your-server.de.1024: P 645:1306(661) ack 86 win 64000
17:18:38.970818 IP static.145.y.x.138.clients.your-server.de.1024 > static.189.y.x.138.clients.your-server.de.3389: P 86:235(149) ack 1306 win 907
17:18:39.017377 IP static.189.y.x.138.clients.your-server.de.3389 > static.145.y.x.138.clients.your-server.de.1024: . ack 235 win 63851
 
I suspect the culprit is
-A POSTROUTING -o vmbr0 -j MASQUERADE

this rewrites the packets going out from vmbr0 to have the ip adress of vmbr0

I don't think this comes from PVE you must have configured this from somewhere else
 
  • Like
Reactions: andy77

About

The Proxmox community has been around for many years and offers help and support for Proxmox VE, Proxmox Backup Server, and Proxmox Mail Gateway.
We think our community is one of the best thanks to people like you!

Get your subscription!

The Proxmox team works very hard to make sure you are running the best software and getting stable updates and security enhancements, as well as quick enterprise support. Tens of thousands of happy customers have a Proxmox subscription. Get yours easily in our online shop.

Buy now!