So connection from outside router using VPN is can’t connect to the server.
This is my firewall rule in server:
br0 is bridge interface that bridging with virtual server inside server.
eno1 is connected to router.
eno2 is not used.
eno3 is connected to other server
eno 4 is connected to Public IP
nmcli c
NAME UUID TYPE DEVICE
eno4 479875f5-537d-4aba-95d5-e0d96b4635e5 ethernet eno4
br0 7a010243-b220-4b2b-9357-d5998c6d8e80 bridge br0
eno2 0bf0f8ff-0dc6-4db4-ab85-d91643ef2386 ethernet eno2
eno3 6bc358b6-1193-3f7e-a16e-4c06a6377d3e ethernet eno3
lo a767791c-cd40-499c-a667-16706ffdd429 loopback lo
virbr0 b9f12251-f2e8-49b8-9799-19ae3542e53b bridge virbr0
vnet0 a1c87b39-21e9-44b2-bdec-0acd4416f85a tun vnet0
bridge-slave-eno1 f59f3584-004c-4700-bdc9-ea29882fe960 ethernet eno1
Every interface must be on some zone. Therefore, one cannot “remove” – one has to “set” the interface to new zone. Besides, the “public” in the default; if interface is not explicitly in any zone, then it is in the default …
Use NetworkManager to set the zone of the connection: nmcli con mod ${connection_of_eno4} connection.zone ${newzone}
Did you already tell what zone you want to use and was it the one that you did add?
This is how I would put eno4 to zone ‘external’ and check what happens:
nmcli -f connection.zone con show eno4
nft list ruleset | grep eno4
nmcli con mod eno4 connection.zone external
nmcli -f connection.zone con show eno4
nft list ruleset | grep eno4
Once you do get the connection to a different zone than the ‘public’, you have to do (up to two) things:
Modify the new zone (e.g. ‘external’) to allow the VPN tunnel
Add FirewallD policies that define how/if traffic is allowed (to be routed/forwarded) between zones
So. help me to back it to public zone first please.
My subnet is 192.168.10.0/24
My server IP 192.168.10.10
My second server IP 192.168.10.5
Second server is normal, can be accessed from outside route using VPN.
As information, I have 192.168.20.0/24 subnet that I used for openvpn user and work normal when user outside LAN connect to this subnet.
But other subnet can’t connect to 192.168.10.10 only as other IP in this subnet accessable.
Other subnet is using openvpn too.
In my mind, I thought to remove firewald and reinstall again in hope it will back to normal but I’m afraid will make worse.
Btw, I tried stop the firewalld service too but no luck, so don’t know what bloking other subnet to this server.
Everything that you have shown indicates that the eno4 is in zone public.
Have you restarted the relevant services or whole server? A service that listens on port (like openvpn) could be affected by interfaces going down and up, so “fall off the boat” due to runtime changes. (Although, changes in firewall rules ought to not affect.)
All FirewallD customizations are stored under /etc/firewalld/, so cleaning there would “reset to defaults”, except the ‘connection.zone’ that is stored in connections.
It would probably help to modify the ‘external’ zone (and policies) before you assign it to use in eno4.
The net.ipv4.ip_forward has to be 1 for at least IPv4 traffic to be forwarded from one interface to another. The ‘external’ zone seems to set that when active, but otherwise one has to set it explicitly.
Was net.ipv4.ip_forward affected by your earlier changes?
Netfilter
The firewall rules dictate whether the forwarded packets are allowed to pass through, or are dropped.
The default is to allow replies on existing connections and one has to explicitly allow just the desired new connections.
In some cases it might be necessary to have dNAT or sNAT (aka masquerade) as well. (The ‘external’ enables that too for its interfaces.)
Shutting down FirewallD removes all filtering. Therefore, everything gets through and is not blocked; no effect on routing. It also removes NAT rules and if connections did depend on NAT, then that disturbs routed traffic.
Routes
Routes dictate where the packets are delivered to. To this machine or via which interface.
When interface gets IP address, the system gets a link-local route to the subnet that the address is member of. The machine may also (optionally) get a default route and static routes.
Logically, machine has at most one (active) default route. A “roadwarrior” VPN config changes default route when tunnel interface activates – “everything” outbound is sent via the tunnel. However, the VPN process must still continue to talk to the VPN partner through original interface.
One can see routes with ip ro (and also in output of nmcli).