Tom Eastep 2005-03-04 2001-2005 Thomas M. Eastep Permission is granted to copy, distribute and/or modify this document under the terms of the GNU Free Documentation License, Version 1.2 or any later version published by the Free Software Foundation; with no Invariant Sections, with no Front-Cover, and with no Back-Cover Texts. A copy of the license is included in the section entitled GNU Free Documentation License. Shorewall Ping management has evolved over time with the latest change coming in Shorewall version 1.4.0. To find out which version of Shorewall you are running, at a shell prompt type /sbin/shorewall version. If that command gives you an error, it's time to upgrade since you have a very old version of Shorewall installed (1.2.4 or earlier). Enabling ping will also enable ICMP-based traceroute. For UDP-based traceroute, see the port information page.

In Shoreall 1.4.0 and later version, ICMP echo-request's are treated just like any other connection request. In order to accept ping requests from zone z1 to zone z2 where the policy for z1 to z2 is not ACCEPT, you need a rule in /etc/shorewall/rules of the form: #ACTION SOURCE DEST PROTO DEST PORT(S) AllowPing z1 z2 To permit ping from the local zone to the firewall: #ACTION SOURCE DEST PROTO DEST PORT(S) AllowPing loc fw If you would like to accept ping by default even when the relevant policy is DROP or REJECT, copy /usr/share/shorewall/action.Drop or /usr/share shorewall/action.Reject respectively to /etc/shorewall and simply add this line to the copy: AllowPing With that rule in place, if you want to ignore ping from z1 to z2 then you need a rule of the form: #ACTION SOURCE DEST PROTO DEST PORT(S) DropPing z1 z2 To drop ping from the internet, you would need this rule in /etc/shorewall/rules: #ACTION SOURCE DEST PROTO DEST PORT(S) DropPing net fw Note that the above rule may be used without changing the action files to prevent your log from being flooded by messages generated from remote pinging.

In Shoreall 1.4.0 and later version, ICMP echo-request's are treated just like any other connection request. In order to accept ping requests from zone z1 to zone z2 where the policy for z1 to z2 is not ACCEPT, you need a rule in /etc/shoreall/rules of the form: #ACTION SOURCE DEST PROTO DEST PORT(S) ACCEPT z1 z2 icmp 8 To permit ping from the local zone to the firewall: #ACTION SOURCE DEST PROTO DEST PORT(S) ACCEPT loc fw icmp 8 If you would like to accept ping by default even when the relevant policy is DROP or REJECT, create /etc/shorewall/icmpdef if it doesn't already exist and in that file place the following command: run_iptables -A icmpdef -p icmp --icmp-type 8 -j ACCEPT With that rule in place, if you want to ignore ping from z1 to z2 then you need a rule of the form: #ACTION SOURCE DEST PROTO DEST PORT(S) DROP z1 z2 icmp 8 To drop ping from the internet, you would need this rule in /etc/shorewall/rules: #ACTION SOURCE DEST PROTO DEST PORT(S) DROP net fw icmp 8 Note that the above rule may be used without any additions to /etc/shorewall/icmpdef to prevent your log from being flooded by messages generated from remote pinging.

In 1.3.14, Ping handling was put under control of the rules and policies just like any other connection request. In order to accept ping requests from zone z1 to zone z2 where the policy for z1 to z2 is not ACCEPT, you need a rule in /etc/shoreall/rules of the form: #ACTION SOURCE DEST PROTO DEST PORT(S) ACCEPT z1 z2 icmp 8 To permit ping from the local zone to the firewall: #ACTION SOURCE DEST PROTO DEST PORT(S) ACCEPT loc fw icmp 8 If you would like to accept ping by default even when the relevant policy is DROP or REJECT, create /etc/shorewall/icmpdef if it doesn't already exist and in that file place the following command: run_iptables -A icmpdef -p icmp --icmp-type 8 -j ACCEPT With that rule in place, if you want to ignore ping from z1 to z2 then you need a rule of the form: #ACTION SOURCE DEST PROTO DEST PORT(S) DROP z1 z2 icmp 8 To drop ping from the internet, you would need this rule in /etc/shorewall/rules: #ACTION SOURCE DEST PROTO DEST PORT(S) DROP net fw icmp 8 The above rule may be used without any additions to /etc/shorewall/icmpdef to prevent your log from being flooded by messages generated from remote pinging. There is one exception to the above description. In 1.3.14 and 1.3.14a, ping from the firewall itself is enabled unconditionally. This suprising feature was removed in version 1.4.0.

There are several aspects to the old Shorewall Ping management: The noping and filterping interface options in /etc/shorewall/interfaces. The FORWARDPING option in /etc/shorewall/shorewall.conf. Explicit rules in /etc/shorewall/rules. There are two cases to consider: Ping requests addressed to the firewall itself; and Ping requests being forwarded to another system. Included here are all cases of packet forwarding including NAT, DNAT rule, Proxy ARP and simple routing. These cases will be covered separately.

For ping requests addressed to the firewall, the sequence is as follows: If neither noping nor filterping are specified for the interface that receives the ping request then the request will be responded to with an ICMP echo-reply. If noping is specified for the interface that receives the ping request then the request is ignored. If filterping is specified for the interface then the request is passed to the rules/policy evaluation.

These requests are always passed to rules/policy evaluation.

Ping requests are ICMP type 8. So the general rule format is: #ACTION SOURCE DEST PROTO DEST PORT(S) <action> <source> <destination> icmp 8 Example 1. Accept pings from the dmz to the net: #ACTION SOURCE DEST PROTO DEST PORT(S) ACCEPT dmz net icmp 8 Drop pings from the net to the firewall: #ACTION SOURCE DEST PROTO DEST PORT(S) DROP net fw icmp 8

If no applicable rule is found, then the policy for the source to the destination is applied. If the relevant policy is ACCEPT then the request is responded to with an ICMP echo-reply. If FORWARDPING is set to Yes in /etc/shorewall/shorewall.conf then the request is responded to with an ICMP echo-reply. Otherwise, the relevant REJECT or DROP policy is used and the request is either rejected or simply ignored.

1.2 2004-01-03 TE Add traceroute reference 1.1 2003-08-23 TE Initial version converted to Docbook XML