This had been working until about June 5. But I was getting ready for major surgery and didn't pursue then.
I have 3 systems. 2 HW, 1VM. The 2 HW systems are connected via Wifi. Below the VM is on the right.
192.168.122.152<---- > 192.168.122.1/192.168.2.127<---->192.168.2.116
With firewalld running on 192.168.2.127 I get the following on 192.168.2.116
[egreshko@acer ~]$ ssh 192.168.122.152 ssh: connect to host 192.168.122.152 port 22: Connection refused [egreshko@acer ~]$ traceroute 192.168.122.152 traceroute to 192.168.122.152 (192.168.122.152), 30 hops max, 60 byte packets 1 192.168.2.127 (192.168.2.127) 2.256 ms 2.834 ms 2.892 ms 2 192.168.2.127 (192.168.2.127) 3.284 ms 3.854 ms 4.398 ms
If I stop the firewall I get..
[egreshko@acer ~]$ ssh 192.168.122.152 Last login: Tue Jun 16 06:21:07 2020 from 2001:b030:112f:2::2 [egreshko@f31k ~]$ exit logout Connection to 192.168.122.152 closed. [egreshko@acer ~]$ traceroute 192.168.122.152 traceroute to 192.168.122.152 (192.168.122.152), 30 hops max, 60 byte packets 1 192.168.2.127 (192.168.2.127) 3.594 ms 3.771 ms 4.345 ms 2 192.168.122.152 (192.168.122.152) 4.653 ms !X 5.260 ms !X 5.532 ms !X
I can connect from 192.168.122.1 to 192.168.122.152 no matter if firewalld is running or not.
[root@meimei ~]# firewall-cmd --get-active-zones libvirt interfaces: virbr0 public interfaces: enp2s0 wlp4s0
What to check? This was working in early June and I doubt I made changes.
--On Tuesday, June 16, 2020 7:40 AM +0800 Ed Greshko ed.greshko@greshko.com wrote:
I have 3 systems.
OS and version? firewalld version and back end used?
For RHEL/CentOS, I start by listing the back end rules.
On 2020-06-16 07:10, Kenneth Porter wrote:
--On Tuesday, June 16, 2020 7:40 AM +0800 Ed Greshko ed.greshko@greshko.com wrote:
I have 3 systems.
OS and version? firewalld version and back end used?
All are Fedora 32. firewalld-0.8.2-3.fc32.noarch. nftables as the backend. I'm pretty sure when I saw the failure I tired iptables and there was no difference.
For RHEL/CentOS, I start by listing the back end rules.
What would be the command to list those?
--On Tuesday, June 16, 2020 8:17 AM +0800 Ed Greshko ed.greshko@greshko.com wrote:
For RHEL/CentOS, I start by listing the back end rules.
What would be the command to list those?
This looks like a good starting point:
https://wiki.nftables.org/wiki-nftables/index.php/Quick_reference-nftables_in_10_minutes
On 2020-06-16 07:24, Kenneth Porter wrote:
--On Tuesday, June 16, 2020 8:17 AM +0800 Ed Greshko ed.greshko@greshko.com wrote:
For RHEL/CentOS, I start by listing the back end rules.
What would be the command to list those?
This looks like a good starting point:
https://wiki.nftables.org/wiki-nftables/index.php/Quick_reference-nftables_in_10_minutes
I see. Well, that make take a bit of time to learn/decipher. Especially during my recovery.
One note, while the route is totally different, I can ssh to the left system in the diagram using ipv6. Still transiting the middle system, of course, since it is the VM host.
On 2020-06-16 07:24, Kenneth Porter wrote:
--On Tuesday, June 16, 2020 8:17 AM +0800 Ed Greshko ed.greshko@greshko.com wrote:
For RHEL/CentOS, I start by listing the back end rules.
What would be the command to list those?
This looks like a good starting point:
https://wiki.nftables.org/wiki-nftables/index.php/Quick_reference-nftables_in_10_minutes
The other thing I found odd is that I did
firewall-cmd --set-log-denied=all
And saw no journal entries showing the reject. I used wireshark. and I do see.
129.168.2.116----->192.168.122.152 Transmission Control Protocol, Src Port: 44870, Dst Port: 22, Seq: 0, Len: 0 and immediately after 192.168.2.127----->192.168.2.116 Internet Control Message Protocol (Port unreachable)
On 2020-06-16 11:43, Ed Greshko wrote:
On 2020-06-16 07:24, Kenneth Porter wrote:
--On Tuesday, June 16, 2020 8:17 AM +0800 Ed Greshko ed.greshko@greshko.com wrote:
For RHEL/CentOS, I start by listing the back end rules.
What would be the command to list those?
This looks like a good starting point:
https://wiki.nftables.org/wiki-nftables/index.php/Quick_reference-nftables_in_10_minutes
The other thing I found odd is that I did
firewall-cmd --set-log-denied=all
And saw no journal entries showing the reject. I used wireshark. and I do see.
129.168.2.116----->192.168.122.152 Transmission Control Protocol, Src Port: 44870, Dst Port: 22, Seq: 0, Len: 0 and immediately after 192.168.2.127----->192.168.2.116 Internet Control Message Protocol (Port unreachable)
I should have tried this earlier. But it seems the issues aren't confined to the libvirt zone. And the symptoms seem odder.
enp2s0 on the "middle (meimei)" host is 192.168.1.18. From the "right (acer2)" host I can ping meimei and ssh to meimei with the firewall active.
However, to a different host 192.168.1.142....
[egreshko@acer ~]$ ping -c 1 -q 192.168.1.142 PING 192.168.1.142 (192.168.1.142) 56(84) bytes of data.
--- 192.168.1.142 ping statistics --- 1 packets transmitted, 1 received, 0% packet loss, time 0ms
But....
[egreshko@acer ~]$ ssh 192.168.1.142 ssh: connect to host 192.168.1.142 port 22: No route to host
--On Wednesday, June 17, 2020 8:07 AM +0800 Ed Greshko ed.greshko@greshko.com wrote:
[egreshko@acer ~]$ ssh 192.168.1.142 ssh: connect to host 192.168.1.142 port 22: No route to host
That error usually means an address issue, not a firewall issue. Are the two machines in the same subnet? Check "ip addr show" for the interfaces involved.
On 2020-06-17 07:19, Kenneth Porter wrote:
--On Wednesday, June 17, 2020 8:07 AM +0800 Ed Greshko ed.greshko@greshko.com wrote:
[egreshko@acer ~]$ ssh 192.168.1.142 ssh: connect to host 192.168.1.142 port 22: No route to host
That error usually means an address issue, not a firewall issue. Are the two machines in the same subnet? Check "ip addr show" for the interfaces involved.
As I mentioned, if the firewall is down, it works just fine.
But, just for completeness.
[egreshko@acer ~]$ ip add show wlp6s0 3: wlp6s0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP group default qlen 1000 link/ether 00:1b:77:d6:ac:c7 brd ff:ff:ff:ff:ff:ff inet 192.168.2.116/24 brd 192.168.2.255 scope global dynamic noprefixroute wlp6s0 valid_lft 69662sec preferred_lft 69662sec inet6 fe80::247c:82ac:e0d7:64af/64 scope link noprefixroute valid_lft forever preferred_lft forever [egreshko@acer ~]$ netstat -rn Kernel IP routing table Destination Gateway Genmask Flags MSS Window irtt Iface 0.0.0.0 211.75.128.254 0.0.0.0 UG 0 0 0 enp8s0 0.0.0.0 192.168.2.5 0.0.0.0 UG 0 0 0 wlp6s0 192.168.1.0 192.168.2.127 255.255.255.0 UG 0 0 0 wlp6s0 192.168.2.0 0.0.0.0 255.255.255.0 U 0 0 0 wlp6s0 192.168.122.0 192.168.2.127 255.255.255.0 UG 0 0 0 wlp6s0 211.75.128.0 0.0.0.0 255.255.255.0 U 0 0 0 enp8s0
On 2020-06-17 08:24, Ed Greshko wrote:
On 2020-06-17 07:19, Kenneth Porter wrote:
--On Wednesday, June 17, 2020 8:07 AM +0800 Ed Greshko ed.greshko@greshko.com wrote:
[egreshko@acer ~]$ ssh 192.168.1.142 ssh: connect to host 192.168.1.142 port 22: No route to host
That error usually means an address issue, not a firewall issue. Are the two machines in the same subnet? Check "ip addr show" for the interfaces involved.
As I mentioned, if the firewall is down, it works just fine.
But, just for completeness.
[egreshko@acer ~]$ ip add show wlp6s0 3: wlp6s0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP group default qlen 1000 link/ether 00:1b:77:d6:ac:c7 brd ff:ff:ff:ff:ff:ff inet 192.168.2.116/24 brd 192.168.2.255 scope global dynamic noprefixroute wlp6s0 valid_lft 69662sec preferred_lft 69662sec inet6 fe80::247c:82ac:e0d7:64af/64 scope link noprefixroute valid_lft forever preferred_lft forever [egreshko@acer ~]$ netstat -rn Kernel IP routing table Destination Gateway Genmask Flags MSS Window irtt Iface 0.0.0.0 211.75.128.254 0.0.0.0 UG 0 0 0 enp8s0 0.0.0.0 192.168.2.5 0.0.0.0 UG 0 0 0 wlp6s0 192.168.1.0 192.168.2.127 255.255.255.0 UG 0 0 0 wlp6s0 192.168.2.0 0.0.0.0 255.255.255.0 U 0 0 0 wlp6s0 192.168.122.0 192.168.2.127 255.255.255.0 UG 0 0 0 wlp6s0 211.75.128.0 0.0.0.0 255.255.255.0 U 0 0 0 enp8s0
Oh, and the ICMP message I see on wireshark coming from 192.168.2.127 (the fw side) is
Type: 3 (Destination unreachable) Code: 13 (Communication administratively filtered)
On Tue, Jun 16, 2020 at 06:40:51AM +0800, Ed Greshko wrote:
This had been working until about June 5. But I was getting ready for major surgery and didn't pursue then.
I have 3 systems. 2 HW, 1VM. The 2 HW systems are connected via Wifi. Below the VM is on the right.
192.168.122.152<---- > 192.168.122.1/192.168.2.127<---->192.168.2.116
With firewalld running on 192.168.2.127 I get the following on 192.168.2.116
[egreshko@acer ~]$ ssh 192.168.122.152 ssh: connect to host 192.168.122.152 port 22: Connection refused [egreshko@acer ~]$ traceroute 192.168.122.152 traceroute to 192.168.122.152 (192.168.122.152), 30 hops max, 60 byte packets  1 192.168.2.127 (192.168.2.127) 2.256 ms 2.834 ms 2.892 ms  2 192.168.2.127 (192.168.2.127) 3.284 ms 3.854 ms 4.398 ms
If I stop the firewall I get..
[egreshko@acer ~]$ ssh 192.168.122.152 Last login: Tue Jun 16 06:21:07 2020 from 2001:b030:112f:2::2 [egreshko@f31k ~]$ exit logout Connection to 192.168.122.152 closed. [egreshko@acer ~]$ traceroute 192.168.122.152 traceroute to 192.168.122.152 (192.168.122.152), 30 hops max, 60 byte packets  1 192.168.2.127 (192.168.2.127) 3.594 ms 3.771 ms 4.345 ms  2 192.168.122.152 (192.168.122.152) 4.653 ms !X 5.260 ms !X 5.532 ms !X
I can connect from 192.168.122.1 to 192.168.122.152 no matter if firewalld is running or not.
[root@meimei ~]# firewall-cmd --get-active-zones libvirt  interfaces: virbr0 public  interfaces: enp2s0 wlp4s0
What to check? This was working in early June and I doubt I made changes.
If you've recently updated firewalld check for AllowZoneDrifting in /etc/firewalld/firewalld.conf.
Based on the bits of info you gave above you may have been unknowingly making use of undesired behavior. See this blog post for further information:
https://firewalld.org/2020/01/allowzonedrifting
Hope that helps. Eric.
On 2020-06-17 03:23, Eric Garver wrote:
If you've recently updated firewalld check for AllowZoneDrifting in /etc/firewalld/firewalld.conf.
Based on the bits of info you gave above you may have been unknowingly making use of undesired behavior. See this blog post for further information:
https://firewalld.org/2020/01/allowzonedrifting
Hope that helps.
No difference when set to "yes". :-(
On Wed, Jun 17, 2020 at 03:34:32AM +0800, Ed Greshko wrote:
On 2020-06-17 03:23, Eric Garver wrote:
If you've recently updated firewalld check for AllowZoneDrifting in /etc/firewalld/firewalld.conf.
Based on the bits of info you gave above you may have been unknowingly making use of undesired behavior. See this blog post for further information:
    https://firewalld.org/2020/01/allowzonedrifting
Hope that helps.
No difference when set to "yes". :-(
Can you show you're firewalld configuration?
# firewall-cmd --list-all-zones
I wonder if you have port forwarding (e.g. 22 -> foo) on the firewalld node. That would hijack the SSH connection attempt.
On 2020-06-17 04:23, Eric Garver wrote:
On Wed, Jun 17, 2020 at 03:34:32AM +0800, Ed Greshko wrote:
On 2020-06-17 03:23, Eric Garver wrote:
If you've recently updated firewalld check for AllowZoneDrifting in /etc/firewalld/firewalld.conf.
Based on the bits of info you gave above you may have been unknowingly making use of undesired behavior. See this blog post for further information:
    https://firewalld.org/2020/01/allowzonedrifting
Hope that helps.
No difference when set to "yes". :-(
Can you show you're firewalld configuration?
# firewall-cmd --list-all-zones
I wonder if you have port forwarding (e.g. 22 -> foo) on the firewalld node. That would hijack the SSH connection attempt.
Just for refresher....
[egreshko@meimei ~]$ sudo firewall-cmd --get-active-zones libvirt interfaces: virbr0 public interfaces: enp2s0 wlp4s0
And then....
[egreshko@meimei ~]$ sudo firewall-cmd --list-all-zones FedoraServer target: default icmp-block-inversion: no interfaces: sources: services: dhcpv6-client ssh ports: protocols: masquerade: no forward-ports: source-ports: icmp-blocks: rich rules:
FedoraWorkstation target: default icmp-block-inversion: no interfaces: sources: services: dhcpv6-client samba-client ssh ports: 1025-65535/udp 1025-65535/tcp protocols: masquerade: no forward-ports: source-ports: icmp-blocks: rich rules:
block target: %%REJECT%% icmp-block-inversion: no interfaces: sources: services: ports: protocols: masquerade: no forward-ports: source-ports: icmp-blocks: rich rules:
dmz target: default icmp-block-inversion: no interfaces: sources: services: ssh ports: protocols: masquerade: no forward-ports: source-ports: icmp-blocks: rich rules:
drop target: DROP icmp-block-inversion: no interfaces: sources: services: ports: protocols: masquerade: no forward-ports: source-ports: icmp-blocks: rich rules:
external target: default icmp-block-inversion: no interfaces: sources: services: ssh ports: protocols: masquerade: yes forward-ports: source-ports: icmp-blocks: rich rules:
home target: default icmp-block-inversion: no interfaces: sources: services: dhcpv6-client mdns mountd nfs nfs3 rpc-bind samba-client ssh ports: protocols: masquerade: no forward-ports: source-ports: icmp-blocks: rich rules:
internal target: default icmp-block-inversion: no interfaces: sources: services: dhcpv6-client mdns samba-client ssh ports: protocols: masquerade: no forward-ports: source-ports: icmp-blocks: rich rules:
libvirt (active) target: ACCEPT icmp-block-inversion: no interfaces: virbr0 sources: services: dhcp dhcpv6 dns mountd nfs nfs3 rpc-bind ssh ports: protocols: icmp ipv6-icmp masquerade: no forward-ports: source-ports: icmp-blocks: rich rules: rule priority="32767" reject
nm-shared target: ACCEPT icmp-block-inversion: no interfaces: sources: services: dhcp dns ports: protocols: icmp ipv6-icmp masquerade: no forward-ports: source-ports: icmp-blocks: rich rules: rule priority="32767" reject
public (active) target: default icmp-block-inversion: no interfaces: enp2s0 wlp4s0 sources: services: dhcpv6-client dns kdeconnect mdns mountd nfs nfs3 rpc-bind samba-client ssh ports: protocols: masquerade: no forward-ports: source-ports: icmp-blocks: rich rules:
trusted target: ACCEPT icmp-block-inversion: no interfaces: sources: services: ports: protocols: masquerade: no forward-ports: source-ports: icmp-blocks: rich rules:
work target: default icmp-block-inversion: no interfaces: sources: services: dhcpv6-client mdns ssh ports: protocols: masquerade: no forward-ports: source-ports: icmp-blocks: rich rules:
On Wed, Jun 17, 2020 at 06:13:37AM +0800, Ed Greshko wrote:
On 2020-06-17 04:23, Eric Garver wrote:
On Wed, Jun 17, 2020 at 03:34:32AM +0800, Ed Greshko wrote:
On 2020-06-17 03:23, Eric Garver wrote:
If you've recently updated firewalld check for AllowZoneDrifting in /etc/firewalld/firewalld.conf.
Based on the bits of info you gave above you may have been unknowingly makingÃÂ useÃÂ ofÃÂ undesiredÃÂ behavior. SeeÃÂ thisÃÂ blogÃÂ postÃÂ forÃÂ furtherÃÂ information:
ÃÂ ÃÂ ÃÂ ÃÂ https://firewalld.org/2020/01/allowzonedrifting
HopeÃÂ thatÃÂ helps.
No difference when set to "yes".ÃÂ :-(
Can you show you're firewalld configuration?
 # firewall-cmd --list-all-zones
I wonder if you have port forwarding (e.g. 22 -> foo) on the firewalld node. That would hijack the SSH connection attempt.
Just for refresher....
[egreshko@meimei ~]$ sudo firewall-cmd --get-active-zones libvirt  interfaces: virbr0 public  interfaces: enp2s0 wlp4s0
And then....
[egreshko@meimei ~]$ sudo firewall-cmd --list-all-zones
[..]
I didn't see anything odd in your configuration. Can you show the actual rulesets? i.e.
# nft list ruleset and # iptables-save
On Thu, Jun 18, 2020 at 03:45:41AM +0800, Ed Greshko wrote:
On 2020-06-18 00:50, Eric Garver wrote:
I didn't see anything odd in your configuration. Can you show the actual rulesets? i.e.
  # nft list ruleset and   # iptables-save
OK....
Due the the length of the output I'll attach 2 .txt files. Hope that is acceptable.
# Generated by iptables-save v1.8.4 on Thu Jun 18 03:40:11 2020 *nat :PREROUTING ACCEPT [42898:17141290] :INPUT ACCEPT [3599:509438] :OUTPUT ACCEPT [12945:1130908] :POSTROUTING ACCEPT [12319:1005476] :LIBVIRT_PRT - [0:0] -A POSTROUTING -j LIBVIRT_PRT -A LIBVIRT_PRT -s 192.168.122.0/24 -d 224.0.0.0/24 -j RETURN -A LIBVIRT_PRT -s 192.168.122.0/24 -d 255.255.255.255/32 -j RETURN -A LIBVIRT_PRT -s 192.168.122.0/24 ! -d 192.168.122.0/24 -p tcp -j MASQUERADE --to-ports 1024-65535 -A LIBVIRT_PRT -s 192.168.122.0/24 ! -d 192.168.122.0/24 -p udp -j MASQUERADE --to-ports 1024-65535 -A LIBVIRT_PRT -s 192.168.122.0/24 ! -d 192.168.122.0/24 -j MASQUERADE
This shows the libvirt network is 192.168.122.0/24. That contradicts what you said in your original email.
"I have 3 systems. 2 HW, 1VM. The 2 HW systems are connected via Wifi. Below the VM is on the right.
192.168.122.152<---->192.168.122.1/192.168.2.127<---->192.168.2.116"
Knowing this and..
[..]
-A FORWARD -j LIBVIRT_FWI -A FORWARD -j LIBVIRT_FWO -A OUTPUT -j LIBVIRT_OUT -A LIBVIRT_FWI -d 192.168.122.0/24 -o virbr0 -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT -A LIBVIRT_FWI -o virbr0 -j REJECT --reject-with icmp-port-unreachable
..this bit. It's not a surprised you're getting ICMP unreachable. libvirt's rules are rejecting the packet. The only reason it works after you disable firewalld is because firewalld flushes the iptables ruleset on shutdown. I bet if you stop firewalld, then restart libvirt it still will _not_ work.
I think in the end you need to setup port forwarding for SSH inside libvirt's configuration.
[..]
On 2020-06-18 04:32, Eric Garver wrote:
On Thu, Jun 18, 2020 at 03:45:41AM +0800, Ed Greshko wrote:
On 2020-06-18 00:50, Eric Garver wrote:
I didn't see anything odd in your configuration. Can you show the actual rulesets? i.e.
  # nft list ruleset and   # iptables-save
OK....
Due the the length of the output I'll attach 2 .txt files. Hope that is acceptable.
# Generated by iptables-save v1.8.4 on Thu Jun 18 03:40:11 2020 *nat :PREROUTING ACCEPT [42898:17141290] :INPUT ACCEPT [3599:509438] :OUTPUT ACCEPT [12945:1130908] :POSTROUTING ACCEPT [12319:1005476] :LIBVIRT_PRT - [0:0] -A POSTROUTING -j LIBVIRT_PRT -A LIBVIRT_PRT -s 192.168.122.0/24 -d 224.0.0.0/24 -j RETURN -A LIBVIRT_PRT -s 192.168.122.0/24 -d 255.255.255.255/32 -j RETURN -A LIBVIRT_PRT -s 192.168.122.0/24 ! -d 192.168.122.0/24 -p tcp -j MASQUERADE --to-ports 1024-65535 -A LIBVIRT_PRT -s 192.168.122.0/24 ! -d 192.168.122.0/24 -p udp -j MASQUERADE --to-ports 1024-65535 -A LIBVIRT_PRT -s 192.168.122.0/24 ! -d 192.168.122.0/24 -j MASQUERADE
This shows the libvirt network is 192.168.122.0/24. That contradicts what you said in your original email.
Well, I got my directions wrong.
The VM is on the left. The Wifi connected system is on the right.
"I have 3 systems. 2 HW, 1VM. The 2 HW systems are connected via Wifi. Below the VM is on the right.
192.168.122.152<---->192.168.122.1/192.168.2.127<---->192.168.2.116"
Knowing this and..
Does that change anything?
[..]
-A FORWARD -j LIBVIRT_FWI -A FORWARD -j LIBVIRT_FWO -A OUTPUT -j LIBVIRT_OUT -A LIBVIRT_FWI -d 192.168.122.0/24 -o virbr0 -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT -A LIBVIRT_FWI -o virbr0 -j REJECT --reject-with icmp-port-unreachable
..this bit. It's not a surprised you're getting ICMP unreachable. libvirt's rules are rejecting the packet. The only reason it works after you disable firewalld is because firewalld flushes the iptables ruleset on shutdown. I bet if you stop firewalld, then restart libvirt it still will _not_ work.
I think in the end you need to setup port forwarding for SSH inside libvirt's configuration.
Even that wouldn't explain why, with the middle system 3 interfaces being 192.168.122.1/192.168.1.18/192.168.2.127 I can't ssh to 192.168.1.142 from 2.116 with the FW up.
On Thu, Jun 18, 2020 at 05:47:21AM +0800, Ed Greshko wrote:
On 2020-06-18 04:32, Eric Garver wrote:
[..]
Even that wouldn't explain why, with the middle system 3 interfaces being 192.168.122.1/192.168.1.18/192.168.2.127Â I can't ssh to 192.168.1.142 from 2.116 with the FW up.
The 192.168.1.0/24 network wasn't shown in your diagram. If it's part of the "public" zone, then that makes sense. firewalld will block the forwarded traffic. The next firewalld feature release has a new feature to allow intra zone forwarding [1].
[1]: https://firewalld.org/2020/04/intra-zone-forwarding
Seems like you have two issues here:
1) libvirt's iptables rules are blocking public --> VM traffic - this must be addressed via libvirt
2) firewalld is blocking public -> public forwarded traffic. - this can be addressed by the feature [1] I mention above - alternatively you can use a direct rule to allow the forwarded traffic
On 2020-06-24 22:34, Eric Garver wrote:
On Thu, Jun 18, 2020 at 05:47:21AM +0800, Ed Greshko wrote:
On 2020-06-18 04:32, Eric Garver wrote:
[..]
Even that wouldn't explain why, with the middle system 3 interfaces being 192.168.122.1/192.168.1.18/192.168.2.127Â I can't ssh to 192.168.1.142 from 2.116 with the FW up.
The 192.168.1.0/24 network wasn't shown in your diagram. If it's part of the "public" zone, then that makes sense. firewalld will block the forwarded traffic. The next firewalld feature release has a new feature to allow intra zone forwarding [1].
Yes, I didn't put that network in the diagram since it seemed to me irrelevant to the initial problem/question.
I can see how the new feature would affect an ssh from .2.116 to .1.142 since both enp2s0 and wlp4s0 are both in the public zone.
[egreshko@meimei ~]$ sudo firewall-cmd --get-active-zones libvirt interfaces: virbr0 public interfaces: enp2s0 wlp4s0
But, the original problem I'm trying to resolve is ssh (or any traffic) from .2.116 to .122.152 which would be between the public and libvirt zones.
Is there a roadmap for the next release?
Seems like you have two issues here:
1) libvirt's iptables rules are blocking public --> VM traffic - this must be addressed via libvirt
But, I get no log messages when I set --set-log-denied=all. Shouldn't those be logged?
And, why did this all work prior to 6/5?
On Thu, Jun 25, 2020 at 08:02:33AM +0800, Ed Greshko wrote:
On 2020-06-24 22:34, Eric Garver wrote:
On Thu, Jun 18, 2020 at 05:47:21AM +0800, Ed Greshko wrote:
On 2020-06-18 04:32, Eric Garver wrote:
[..]
Even that wouldn't explain why, with the middle system 3 interfaces being 192.168.122.1/192.168.1.18/192.168.2.127ÃÂ I can't ssh to 192.168.1.142 from 2.116 with the FW up.
The 192.168.1.0/24 network wasn't shown in your diagram. If it's part of the "public" zone, then that makes sense. firewalld will block the forwarded traffic. The next firewalld feature release has a new feature to allow intra zone forwarding [1].
Yes, I didn't put that network in the diagram since it seemed to me irrelevant to the initial problem/question.
I can see how the new feature would affect an ssh from .2.116 to .1.142 since both enp2s0 and wlp4s0 are both in the public zone.
[egreshko@meimei ~]$ sudo firewall-cmd --get-active-zones libvirt  interfaces: virbr0 public  interfaces: enp2s0 wlp4s0
But, the original problem I'm trying to resolve is ssh (or any traffic) from .2.116 to .122.152 which would be between the public and libvirt zones.
Right. And we already diagnosed that. libvirt's rules are dropping the packets, not firewalld.
Is there a roadmap for the next release?
The upstream project board.
https://github.com/orgs/firewalld/projects/1#card-26270769
Seems like you have two issues here:
 1) libvirt's iptables rules are blocking public --> VM traffic    - this must be addressed via libvirt
But, I get no log messages when I set --set-log-denied=all. Shouldn't those be logged?
No. Because firewalld is not the one dropping the packets here. libvirt is the one dropping. firewalld can't influence libvirt's rules.
And, why did this all work prior to 6/5?
I don't know. Maybe something changed in libvirt?
On 2020-06-25 22:21, Eric Garver wrote:
On Thu, Jun 25, 2020 at 08:02:33AM +0800, Ed Greshko wrote:
On 2020-06-24 22:34, Eric Garver wrote:
On Thu, Jun 18, 2020 at 05:47:21AM +0800, Ed Greshko wrote:
On 2020-06-18 04:32, Eric Garver wrote:
[..]
Even that wouldn't explain why, with the middle system 3 interfaces being 192.168.122.1/192.168.1.18/192.168.2.127ÃÂ I can't ssh to 192.168.1.142 from 2.116 with the FW up.
The 192.168.1.0/24 network wasn't shown in your diagram. If it's part of the "public" zone, then that makes sense. firewalld will block the forwarded traffic. The next firewalld feature release has a new feature to allow intra zone forwarding [1].
Yes, I didn't put that network in the diagram since it seemed to me irrelevant to the initial problem/question.
I can see how the new feature would affect an ssh from .2.116 to .1.142 since both enp2s0 and wlp4s0 are both in the public zone.
[egreshko@meimei ~]$ sudo firewall-cmd --get-active-zones libvirt  interfaces: virbr0 public  interfaces: enp2s0 wlp4s0
But, the original problem I'm trying to resolve is ssh (or any traffic) from .2.116 to .122.152 which would be between the public and libvirt zones.
Right. And we already diagnosed that. libvirt's rules are dropping the packets, not firewalld.
Seems like you have two issues here:
 1) libvirt's iptables rules are blocking public --> VM traffic    - this must be addressed via libvirt
But, I get no log messages when I set --set-log-denied=all. Shouldn't those be logged?
No. Because firewalld is not the one dropping the packets here. libvirt is the one dropping. firewalld can't influence libvirt's rules.
Sorry, I must be missing something. When you say "libvirt's rules" aren't they the rules of the libvirt zone? They can't be "adjusted" with the usual firewall-cmd commands?
Also, wouldn't one expect the rules to be the same for IPv4 and IPv6? Hope the network diagram attachment makes it.
Configured on the router are
Forward Port 22 from 211.75.128.214 to 192.168.122.152 Static route pointing 192.168.122.0/24 to 192.168.1.18 Static route pointing 2001:b030:112f:2::/64 to 2001:b030:112f::140e
From a host with IPs of 211.75.128.211 and 2001:470:67:cce::5 this works.
[egreshko@acer ~]$ ssh 2001:b030:112f:2::4 Last login: Thu Jun 25 22:15:30 2020 from 2001:470:66:cce::2
While this "hangs". (I think because ICMP may be blocked at some point. Too late in my day to check)
[egreshko@acer ~]$ ssh 211.75.128.214 ssh: connect to host 211.75.128.214 port 22: Connection timed out
On Thu, Jun 25, 2020 at 10:55:45PM +0800, Ed Greshko wrote:
On 2020-06-25 22:21, Eric Garver wrote:
On Thu, Jun 25, 2020 at 08:02:33AM +0800, Ed Greshko wrote:
On 2020-06-24 22:34, Eric Garver wrote:
On Thu, Jun 18, 2020 at 05:47:21AM +0800, Ed Greshko wrote:
On 2020-06-18 04:32, Eric Garver wrote:
[..]
Even that wouldn't explain why, with the middle system 3 interfaces being 192.168.122.1/192.168.1.18/192.168.2.127ÃâàI can't ssh to 192.168.1.142 from 2.116 with the FW up.
The 192.168.1.0/24 network wasn't shown in your diagram. If it's part of the "public" zone, then that makes sense. firewalld will block the forwarded traffic. The next firewalld feature release has a new feature to allow intra zone forwarding [1].
Yes, I didn't put that network in the diagram since it seemed to me irrelevant to the initial problem/question.
I can see how the new feature would affect an ssh from .2.116 to .1.142 since both enp2s0 and wlp4s0 are both in the public zone.
[egreshko@meimei ~]$ sudo firewall-cmd --get-active-zones libvirt ÃÂ interfaces: virbr0 public ÃÂ interfaces: enp2s0 wlp4s0
But, the original problem I'm trying to resolve is ssh (or any traffic) from .2.116 toÃÂ .122.152 which would be between the public and libvirt zones.
Right. And we already diagnosed that. libvirt's rules are dropping the packets, not firewalld.
Seems like you have two issues here:
ÃÂ 1) libvirt's iptables rules are blocking public --> VM traffic ÃÂ ÃÂ ÃÂ - this must be addressed via libvirt
But, I get no log messages when I set --set-log-denied=all.ÃÂ Shouldn't those be logged?
No. Because firewalld is not the one dropping the packets here. libvirt is the one dropping. firewalld can't influence libvirt's rules.
Sorry, I must be missing something. When you say "libvirt's rules" aren't they the rules of the libvirt zone? They can't be "adjusted" with the usual firewall-cmd commands?
There are two things:
1) the libvirt zone - these are managed through firewalld and visible in firewalld UIs
2) libvirt's iptables rules - there are completely separate and independent from firewalld - this is what's blocking the traffic to your VM
Also, wouldn't one expect the rules to be the same for IPv4 and IPv6? Hope the network diagram attachment makes it.
I don't recall what libvirt does for IPv6. But it's a different matter because IPv6 likely is using NAT/masquerade.
Configured on the router are
Forward Port 22 from 211.75.128.214 to 192.168.122.152 Static route pointing 192.168.122.0/24 to 192.168.1.18 Static route pointing 2001:b030:112f:2::/64 to 2001:b030:112f::140e
From a host with IPs of 211.75.128.211 and 2001:470:67:cce::5 this works.
[egreshko@acer ~]$ ssh 2001:b030:112f:2::4 Last login: Thu Jun 25 22:15:30 2020 from 2001:470:66:cce::2
While this "hangs". (I think because ICMP may be blocked at some point. Too late in my day to check)
[egreshko@acer ~]$ ssh 211.75.128.214 ssh: connect to host 211.75.128.214 port 22: Connection timed out
firewalld-users mailing list -- firewalld-users@lists.fedorahosted.org To unsubscribe send an email to firewalld-users-leave@lists.fedorahosted.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedorahosted.org/archives/list/firewalld-users@lists.fedorahos...
On 2020-06-26 00:49, Eric Garver wrote:
There are two things:
- the libvirt zone
- these are managed through firewalld and visible in firewalld UIs
- libvirt's iptables rules
- there are completely separate and independent from firewalld - this is what's blocking the traffic to your VM
And there is no way to see what those rules are and verify this? I'd like to submit a bugzilla, so would you know what component it should be filed against?
Also, wouldn't one expect the rules to be the same for IPv4 and IPv6? Hope the network diagram attachment makes it.
I don't recall what libvirt does for IPv6. But it's a different matter because IPv6 likely is using NAT/masquerade.
Well, all of my IPv6 addresses are public and assigned by my ISP. I don't think there is NAT/masquerading needed/involved.
On Fri, Jun 26, 2020 at 02:12:20AM +0800, Ed Greshko wrote:
On 2020-06-26 00:49, Eric Garver wrote:
There are two things:
- the libvirt zone
- these are managed through firewalld and visible in firewalld UIs
- libvirt's iptables rules
- there are completely separate and independent from firewalld - this is what's blocking the traffic to your VMAnd there is no way to see what those rules are and verify this? I'd like to submit a bugzilla, so would you know what component it should be filed against?
I'm not sure what you're planning to file. I think it's working as designed. If you want to open a port for you VM, then you need to do that through libvirt.
See here: https://wiki.libvirt.org/page/Networking#Forwarding_Incoming_Connections
Also, wouldn't one expect the rules to be the same for IPv4 and IPv6?ÃÂ Hope the network diagram attachment makes it.
I don't recall what libvirt does for IPv6. But it's a different matter because IPv6 likely is using NAT/masquerade.
Well, all of my IPv6 addresses are public and assigned by my ISP. I don't think there is NAT/masquerading needed/involved.
There shouldn't be.
On 2020-06-26 03:00, Eric Garver wrote:
I'm not sure what you're planning to file. I think it's working as designed. If you want to open a port for you VM, then you need to do that through libvirt.
See here: https://wiki.libvirt.org/page/Networking#Forwarding_Incoming_Connections
OK, yes it certainly does look like all is working as designed. I'd been thrown since it was all working for me until recently. In fact, it never should have worked.
Well, since IPv6 works for me as I would want I think I'll just go with that as the method described in the link is as it says "a hack" and only provides access to a single VM and a single port. I use a much larger number of VMs and ports.
Thanks for the link and thanks much for your time.
On 2020-06-26 03:00, Eric Garver wrote:
See here: https://wiki.libvirt.org/page/Networking#Forwarding_Incoming_Connections
Oh, I reread this and it finally dawned on me....
"By default, guests that are connected via a virtual network with <forward mode='nat'/> can make any outgoing network connection they like. Incoming connections are allowed from the host, and from other guests connected to the same libvirt network, but all other incoming connections are blocked by iptables rules."
So, I changed the mode to "route" and I get the behavior I need for all the VM's and IPv4.
So....thanks once again.
firewalld-users@lists.fedorahosted.org
-
Ed Greshko -
Eric Garver -
Kenneth Porter