Actually only on some ports, but could simply related to the fact that these ports are the ones widely used (mainly https)
Strange issue with firewall rules
- Thread starter buzzzo
- Start date
I've responded above, i've grouped port to be allowed on one rules , which is translated in a dport iptables rule.
May you execute the policy load script manually and paste the output?
Bash:
/etc/fwcloud/fwcloud.shOne interesting thing i've noted:
1) every firewall vm is behind a "real" firewall (fortinet or watchguard) , so to reach the fwcloud firewall (aka the vm) one should traverse the "real" firewall
(please excuse me to use the term "real" , it's just for simplicity)
2) so test1: go from my lan to the dmz (behind fortinet) where fwcloud firewall resides: denied will be logged
3) test 2: try to connect on the same subnet (so no routing over the "real" firewall is involved): no denied is logged.
So seems that interactions with other network equipment is causing the issue.
The strange thing is that the issue happens with two different brands of "real" firewall.
1) every firewall vm is behind a "real" firewall (fortinet or watchguard) , so to reach the fwcloud firewall (aka the vm) one should traverse the "real" firewall
(please excuse me to use the term "real" , it's just for simplicity)
2) so test1: go from my lan to the dmz (behind fortinet) where fwcloud firewall resides: denied will be logged
3) test 2: try to connect on the same subnet (so no routing over the "real" firewall is involved): no denied is logged.
So seems that interactions with other network equipment is causing the issue.
The strange thing is that the issue happens with two different brands of "real" firewall.
WCloud.net - Loading firewall policy generated: Mon Jan 09 2023 18:09:27 GMT+0100 (Central European Standard Time)
# Warning: ip6tables-legacy tables present, use ip6tables-legacy to see them
# Warning: ip6tables-legacy tables present, use ip6tables-legacy to see them
# Warning: ip6tables-legacy tables present, use ip6tables-legacy to see them
***********************
* FILTER TABLE (IPv4) *
***********************
INPUT CHAIN
-----------
Rule 1 (ID: 827)
Rule 2 (ID: 372)
Rule 3 (ID: 384)
Rule 4 (ID: 425)
Rule 5 (ID: 385)
Rule 6 (ID: 386)
Rule 7 (ID: 387)
Rule 8 (ID: 403)
Rule 9 (ID: 389)
Rule 10 (ID: 388)
Rule 11 (ID: 874)
Rule 12 (ID: 374)
OUTPUT CHAIN
------------
Rule 1 (ID: 380)
Rule 2 (ID: 382)
FORWARD CHAIN
-------------
Rule 1 (ID: 828)
Rule 2 (ID: 376)
Rule 3 (ID: 378)
********************
* NAT TABLE (IPv4) *
********************
SNAT
----
DNAT
----
***********************
* FILTER TABLE (IPv6) *
***********************
INPUT CHAIN
-----------
Rule 1 (ID: 829)
Rule 2 (ID: 373)
Rule 3 (ID: 375)
OUTPUT CHAIN
------------
Rule 1 (ID: 381)
Rule 2 (ID: 383)
FORWARD CHAIN
-------------
Rule 1 (ID: 830)
Rule 2 (ID: 377)
Rule 3 (ID: 379)
********************
* NAT TABLE (IPv6) *
********************
SNAT
----
DNAT
----
OPTIONS
-------
net.ipv4.conf.all.forwarding = 0
net.ipv6.conf.all.forwarding = 0
Then the solution is to replace your "real" firewall with another one managed by means of FWCloud, you can even use a vm based firewall cluster ... I'm just joking ;-)
Maybe your FortiGate perimetral firewall is altering the network traffic in some way that affects the state that FWCloud uses for allow STABLISHED,RELATED connections.
Are you making NAT or altering this traffic?
As you have pointed in a previous post, one of the ports with which you have problems is TCP 443, the standard port for HTTPS communications. If you have SSL inspection allowed in your FortiGate it is possible that is altering the network flow.
Thank you for posting the output of the FWCloud script, there is no error and the policy is loading fine.
Nevertheless, the problem seems to be generated by the FortiGate as you have already pointed in your previous post.
Maybe your FortiGate perimetral firewall is altering the network traffic in some way that affects the state that FWCloud uses for allow STABLISHED,RELATED connections.
Are you making NAT or altering this traffic?
As you have pointed in a previous post, one of the ports with which you have problems is TCP 443, the standard port for HTTPS communications. If you have SSL inspection allowed in your FortiGate it is possible that is altering the network flow.
Thank you for posting the output of the FWCloud script, there is no error and the policy is loading fine.
Nevertheless, the problem seems to be generated by the FortiGate as you have already pointed in your previous post.
Thx, issue #2 seems related to this. I'm investigating a little bit for issue 1.
Thx for your help
I think that issue 1 will be related with the FortiGate too.
You are welcome, if need more help contact us again.
You are welcome, if need more help contact us again.
Thx, what are the risks to convert the firewall to "stateless" ? i'm just using fwcloud as host firewall so maybe I could disable the stateful feature.
No risk, only have in mind that you are working with a stateless firewall and maybe you will need to create additional rules.
Your firewall is only for the INPUT chain and you don't need to create rules for the OUTBOUND traffic because the default rule allows it all. Then the change should be quite simple.
If the firewall is not yet in production you can change it in the options tab of it and try.
Please, let me know how has gone.
Your firewall is only for the INPUT chain and you don't need to create rules for the OUTBOUND traffic because the default rule allows it all. Then the change should be quite simple.
If the firewall is not yet in production you can change it in the options tab of it and try.
Please, let me know how has gone.
Hi, After this log:
[Jan10 09:20] RULE ID 874 [REJECT] IN=ens192 OUT= MAC=00:50:56:a4:16:d2:aa:00:00:18:8f:2e:08:00 SRC=172.16.1.109 DST=172.16.1.103 LEN=40 TOS=0x00 PREC=0x00 TTL=64 ID=23244 DF PROTO=TCP SPT=41230 DPT=443 WINDOW=0 RES=0x00 RST URGP=0
I'm not too sure it would be a fortigate's problem.
As you can see bot src and dst are on the same subnet, so no routing or packet manipulation by third party device is involved.
[Jan10 09:20] RULE ID 874 [REJECT] IN=ens192 OUT= MAC=00:50:56:a4:16:d2:aa:00:00:18:8f:2e:08:00 SRC=172.16.1.109 DST=172.16.1.103 LEN=40 TOS=0x00 PREC=0x00 TTL=64 ID=23244 DF PROTO=TCP SPT=41230 DPT=443 WINDOW=0 RES=0x00 RST URGP=0
I'm not too sure it would be a fortigate's problem.
As you can see bot src and dst are on the same subnet, so no routing or packet manipulation by third party device is involved.
Who is the owner of the source IP (172.16.1.109) ? Is the FortiGate ?
If you try the communication from any other host connected to the same network, goes it fine ?
If you try the communication from any other host connected to the same network, goes it fine ?
No, 172.16.1.109 is just another vm on the same subnet (layer 2). no routing is involved between 2 parts.
As you can see in the log, the received packet is a TCP RST (https://www.pico.net/kb/what-is-a-tcp-reset-rst/).
Have you checked the communication from this host? Goes it fine?
Have you checked the communication from this host? Goes it fine?