user12345 wrote: ↑2019/07/31 02:42:34
I presume that as long as there are routes configured on the server to route packets from one router to another, then it should be fine?
Another thing is that I am using firewalld, instead of iptables. Firewalld is the default firewall for CentOS 7.
The actual, active filter rules are in the kernel memory.
Firewalld is a service. It has replaced the iptables service. Both load rules to kernel, but firewalld is more elaborate.
Both use same tool to read and write filter rules. That tool is
iptables.
The iptables.service is a simple script that runs 'iptables' on boot to load rules from file to kernel.
The iptables commands that I did show do read and show the rules. That provides a different view than firewall-cmd.
(I do configure with firewalld, but still like to peek with iptables.)
Part of
iptables -vnL FORWARD:
Code: Select all
Chain FORWARD (policy ACCEPT 0 packets, 0 bytes)
pkts bytes target prot opt in out source destination
11 1898 ACCEPT all -- ens37 * 0.0.0.0/0 0.0.0.0/0
37 8109 ACCEPT all -- ens33 * 0.0.0.0/0 0.0.0.0/0
0 0 ACCEPT all -- ens37 * 0.0.0.0/0 0.0.0.0/0
0 0 ACCEPT all -- ens33 * 0.0.0.0/0 0.0.0.0/0
Order of rules is important, but for now lets just note that
* 11 packets have arrived via ens37 and have been accepted to be routed
* 37 packets have arrived via ens33 and have been accepted to be routed
Part of
iptables -vnL INPUT:
Code: Select all
Chain INPUT (policy ACCEPT 0 packets, 0 bytes)
pkts bytes target prot opt in out source destination
0 0 ACCEPT all -- * * 0.0.0.0/0 0.0.0.0/0 ctstate RELATED,ESTABLISHED
0 0 ACCEPT all -- lo * 0.0.0.0/0 0.0.0.0/0
34 7280 INPUT_direct all -- * * 0.0.0.0/0 0.0.0.0/0
34 7280 INPUT_ZONES_SOURCE all -- * * 0.0.0.0/0 0.0.0.0/0
34 7280 INPUT_ZONES all -- * * 0.0.0.0/0 0.0.0.0/0
0 0 DROP all -- * * 0.0.0.0/0 0.0.0.0/0 ctstate INVALID
34 7280 REJECT all -- * * 0.0.0.0/0 0.0.0.0/0 reject-with icmp-host-prohibited
34 packets have arrived to this CentOS 7 host. None of them did match any specific rule and therefore they were all rejected.
All the firewalld "services and ports" are only in the chain
IN_public_allow. Those 34 packets did not match any of them.
The "IN" rules are not used for routed (forwarded) traffic.
I have machines that do route traffic. They don't have anything like "ACCEPT all -- ens37 *" in their FORWARD:
Code: Select all
$ iptables -S FORWARD
-P FORWARD ACCEPT
-A FORWARD -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT
-A FORWARD -i lo -j ACCEPT
-A FORWARD -j FORWARD_direct
-A FORWARD -j FORWARD_IN_ZONES_SOURCE
-A FORWARD -j FORWARD_IN_ZONES
-A FORWARD -j FORWARD_OUT_ZONES_SOURCE
-A FORWARD -j FORWARD_OUT_ZONES
-A FORWARD -m conntrack --ctstate INVALID -j DROP
-A FORWARD -j REJECT --reject-with icmp-host-prohibited
Routes alone do not make a router. Every machine has routes. Whenever the system gets a packet, it makes a "routing decision":
* Is this for me? If yes, hand it to local process (through INPUT filter).
* If no, throw it out from interface that the routes say (through FORWARD filter).
However, forwarding requires that it is enabled in the kernel:
Code: Select all
$ sysctl net.ipv4.ip_forward
net.ipv4.ip_forward = 1
If that value is 0, you can enable it for this session with:
To have it persist after reboot, one has to write it to a file:
Code: Select all
echo "sysctl net.ipv4.ip_forward = 1" >> /etc/sysctl.d/90-enable-router.conf
(I don't actually have such file, for certain firewalld zone combinations set it for me.)
Lets recap:
1. A packet from "cisco-1" arrives from ens33 and has destination address "cisco-2"
2. Routes state that the packet has to be send out from ens37
3. ip_forward == 1, routing is enabled
4. Firewall rules in FORWARD allow "from ens33 to ens37"
5. Succee
The replies are handled similarly.
IMHO, comfy way to see the routes:
Oh my,
You have both interfaces on zone public and you have enabled masquerade (aka SNAT) on zone public.
That changes the story:
1. A packet from "cisco-1" arrives from ens33 and has destination address "cisco-2"
2. Routes state that the packet has to be send out from ens37
3. ip_forward == 1, routing is enabled
4. Firewall rules in FORWARD allow "from ens33 to ens37"
5. SNAT: Sender address is set to IP of ens37.
* cisco-2 receives packet and replies to IP-of-ens37
1. A packet from "cisco-2" arrives from ens37 and has destination address "IP-of-ens37"
2. Masquerade notices reply and changes destination to "cisco-1"
3. Routes state that the packet has to be send out from ens33
4. ip_forward == 1, routing is enabled
5. Firewall rules in FORWARD allow "reply in existing connection"
6. SNAT: Sender address is set to IP of ens33.
* cisco-1 receives packet "from IP-of-ens33". That is unexpected. We did just call cisco-2. That does not reply.
Why do you have the MASQUERADE on?
cisco-1 should have effective route: "to cisco-2, send via IP-of-ens33"
cisco-2 should have effective route: "to cisco-1, send via IP-of-ens37"
With those the SNAT is not needed. Definitely not to both directions.