Hi all,
I usually drop all forwards as the last rule and allow only known tracked traffic. Now, I have an strange problem for creating a rule for allowing ping from one server to another.
I should be able to do this using this rule:
add action=accept chain=forward comment=Ping protocol=icmp src-address=192.168.9.220
allowing it to ping everywhere.
But, additionally I need to add the following rule to make it work:
add action=accept chain=forward comment=Established connection-state=established dst-address=192.168.9.220
Can you help me understand the problem? Why should I add this “connection-state=established” rule?
Thanks
CZFan
October 12, 2020, 10:56am
2
Hi all,
I usually drop all forwards as the last rule and allow only known tracked traffic. Now, I have an strange problem for creating a rule for allowing ping from one server to another.
I should be able to do this using this rule:
add action=accept chain=forward comment=Ping protocol=icmp src-address=192.168.9.220
allowing it to ping everywhere.
But, additionally I need to add the following rule to make it work:
add action=accept chain=forward comment=Established connection-state=established dst-address=192.168.9.220
Can you help me understand the problem? Why should I add this “connection-state=established” rule?
Thanks
The first rule will allow from the source IP Address, but will not allow the return traffic, i.e. ping reply packets.
The 2nd rule will allow this, as the reply packets is seen as part of the sent packets, i.e. related / established
anav
October 12, 2020, 1:27pm
3
Hmmmm, not quite sure I buy that!
My understanding is that a firewall rule traffic allowing traffic from one subnet to another (for example vlanA to printer on vlanB) means that
VlanA can initiate traffic and reach VlanB. The key being originate!!
The return traffic from VlanB in response to a query from VlanA, is supposed to be allowed (as this traffic is IN RESPONSE and NOT originated on VlanB).
originated = unsolicited.
I have no doubt that you are right, but you have to do a much better sell job to convince me!!! I am all ears!!
(as for the OP, I would suggest trying to identify a destination address and then see if it works, as allowing somebody to SEND (to anywhere) may be too vague?
Sob
October 12, 2020, 1:37pm
4
It would with default firewall. But there can be something completely different now.
anav
October 12, 2020, 1:59pm
5
Anav translating Sob’s post for the OP.
Hello Mr OP, please provide the effing config ( I said please but I know what you were thinking)
/export hide-sensitive file=anynameyouwish
Hmmmm, not quite sure I buy that!
My understanding is that a firewall rule traffic allowing traffic from one subnet to another (for example vlanA to printer on vlanB) means that
VlanA can initiate traffic and reach VlanB. The key being originate!!
The return traffic from VlanB in response to a query from VlanA, is supposed to be allowed (as this traffic is IN RESPONSE and NOT originated on VlanB).
originated = unsolicited.
I have no doubt that you are right, but you have to do a much better sell job to convince me!!! I am all ears!!
(as for the OP, I would suggest trying to identify a destination address and then see if it works, as allowing somebody to SEND (to anywhere) may be too vague?
Thanks for your reply. I agree with you and I couldn’t buy that.
Hi all,
I usually drop all forwards as the last rule and allow only known tracked traffic. Now, I have an strange problem for creating a rule for allowing ping from one server to another.
I should be able to do this using this rule:
add action=accept chain=forward comment=Ping protocol=icmp src-address=192.168.9.220
allowing it to ping everywhere.
But, additionally I need to add the following rule to make it work:
add action=accept chain=forward comment=Established connection-state=established dst-address=192.168.9.220
Can you help me understand the problem? Why should I add this “connection-state=established” rule?
Thanks
The first rule will allow from the source IP Address, but will not allow the return traffic, i.e. ping reply packets.
The 2nd rule will allow this, as the reply packets is seen as part of the sent packets, i.e. related / established
Thanks for your reply. I might accept this for ping reply. But, it can not be true for TCP connections. Can it be?
Do you know something about that changed thing?
I remember working with as I said without the second established rule!
anav
October 26, 2020, 12:30pm
9
Post your config if you want help, already asked once…