Search results

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?

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 ?

Hi Jeremy, For the RPM package generation we use this YAML code as part of the CI (GitHub Actions) of the FWCloud-Agent repository: rpm-package: needs: [build] runs-on: ubuntu-latest name: RPM package steps: - uses: actions/checkout@v2 - name: Install required...

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...

I think that issue 1 will be related with the FortiGate too. You are welcome, if need more help contact us again.

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...

May you execute the policy load script manually and paste the output? /etc/fwcloud/fwcloud.sh

Please, don't forget to answer my last question:

On question more ... the problem arises with all ports that you have allowed in your firewall or only with some of them?

That is not normal in a so simple firewall. Is it possible that you put here the policy load script generated by the firewall compilation process? And can you copy and paste the output of the ip a command executed in your firewall?

We have firewalls over the VMware hypervisor. The hypervisor should not be the problem. Why have you created this custom "catchall" rule if you already have the default catch-all rule? Is this a stateful firewall or stateless? The screenshot is for the input policy?

Can you put here screenshots of your firewall policy?

Forget about it, if it is a fresh Linux install it not should be the origin of the problem. I think that the tcpdump command output will be useful for analyze the problem.

We usually use vm as firewalls over Proxmox hypervisors. I think that the problem is not here. Maybe you are receiving out-of-order packages ... In the log I see an ACK SYN packet that can come from a previous TCP flow already closed in the firewall, is it possible? Have you altered the TCP...

Hi, I would like to help you in the resolution of this problem, but for it I need more information and feedback. It is not normal this problem in a so simple stateful firewall like the one you have. May you answer the questions of my previous post? Maybe a tcpdump trace will help. Can you run...

Is the communication form your firewall with the MySQL server working? Have you compiled and installed the policy in the firewall? Can you attach the policy script?

Hi, This is not OUTBOUND traffic, it is INBOUND. Look at this part of your log: IN=ens18 OUT= If this where OUTBOUND traffic the OUT field will have the name of the OUTBOUND traffic interface. For some reason the original host is using the TCP port 3306 as source port.

Ok, you are welcome.

We will analyze the problems you comment. Nevertheless have in mind that the firewall policy apply and the import process is not a bidirectional process, you will not get exactly the same result when you import the policy firewall applied.

Ok, great, then your problem is already solved, isn't it?