viryedi windah zbysio

[Lorrine Hatala]

I have a series of Ubuntu 10.04 servers and each one has ufw firewall enabled. I have allowed port 22 (for SSH) and 80 (if it's a webserver). My question is that I am trying to enable icmp echo response (ping reply).

Of course, be sure that this is really the problem. My issue was that my computer was blocking pings from getting out to the network where the server I was trying to ping existed. I ended up using a web site that was already out on the internet to do the ping for me (e.g. ).

If you are still having problems, maybe it is your VirtualBox or VMWare network settings. I often use NAT addressing and so I need to go to Devices/Network/Network Settings... -> Advanced -> Port Forwarding and add a rule to map host to guest ports for port 22.

Hence, if there are no listeners/subscribers client nodes downstream (that wish to receive multicast packets from upstream (W)WAN) the rule can be disabled for (W)WAN without any caveats/disturbance on the general ipv6 connectivity?

All the below listed are supposedly a response from a remote node to a connection attempt initiated the local router and thus seems non-essential in the fw (W)WAN context as already covered by conntrack (established) - as opposed to unsolicited ingress?

I have read the RFC and what I asked does not seem to be detrimental because those packets types are traversing the fw uninhibited when the connection is solicited/initiated by the router due to conntrack (established).

But what is the purpose to allowing such packets when being unsolicited from a remote/foreign WAN source, unless running some server side service on the router that is exposed to WAN, which most CPE/SOHO routers are likely not, contrary to servers that provide content/service on public domains?

With that background the aforementioned rules make sense. Though I do not understand the benefit of conntrack being disabled by default on the WAN, weak hardware where conntrack is too costly on the CPU?

I am not familiar with the intricacy of that protocol and to which extent/volume it utilizes icmp6 and whether 1000/s is needed indeed. It just seems an awful lot considering unsolicited traffic being accepted (packet flood/storm).

Have been mulling over the IPCMPv6 forwarding rules that ship with vanilla FW3 and those do not seem to make sense, notwithstanding wondering whether the downstream clients are at all subjected to the IPv6 firewall part, considering/reasoning:

Forwarding ICMPv6 packets from WAN does not appear necessary with the CPE's downstream client (LAN) having an IPv6 GUA and thus being in WAN IPv6 address space (contrary to ULA IPv4 behind NAT) - the downstream client's interface with the IPv6 GUA being subjected to the ISP's firewall ingress rules and the client's own firewall ingress rules but not the CPE's.

Any traffic not terminating on the router itself is forwarded traffic from iptables pov. Traffic towards IP addresses not assigned to any of the routers local interfaces is covered by FORWARD rules, not INPUT (ingress) ones.

Sure, that makes sense for IPv4 where the LAN client is commonly only having a ULA behind a NAT of single GUA that covers the CPE and all its clients and thus the CPE's firewall takes an active role in the packet routing decision (translate/forward from GUA to ULA).

But for IPv6, save for NAT6 NAT64, the CPE's client has it is own GUA, different from any other client and the CPE itself and routing is already provided by routers' routing tables and the IPv6 prefix in the IPv6 header. Forwarding ICMPv6 via firewall thus seems not only superfluous but may unnecessarily consume CPU cycles and confuse networking.

Sorry, I am not following. Inbound forwarded ICMPv6 is rejected by default unless it is classified as related, so made in response to a connection initiated from within, therefore it is needed to establish explicit rules allowing inbound ICMPv6. These rules are in accordance with RFC 4890, section 4.3 "Recommendations for ICMPv6 Transit Traffic"

You absolutely can NOT drop ICMPv6 at the router. For example, there is no router fragmentation in IPv6, if a packet is too big to go through one of the many hops along its journey, the router at that hop sends an ICMP message to the origin saying "the max MTU is x" and the client device behind your router NEEDS to get that packet or it will not be able to talk ipv6. I've seen this cause all sorts of problems.. People with strong ipv4 security backgrounds always want to drop ICMP6 but you really should allow all ICMP6 traffic, and at best rate limit it.

Is the firewall actually aware of the CPE's IPv6 GUA and concludes that any packet with a different destination IPv6 as forward? If that is the case it all makes sense and I might have missed that bit (IPv6 address space awareness) when looking into FW3 source code.

I assume you mean CPE is the OpenWrt router. In that case, the router absolutely knows that a packet that hits its WAN interface destined to a GUA on its LAN is supposed to be forwarded... that's what it does, it's a router.

I have 2 networks in 2 different security zones. I have been trying to set up the firewall (PA-500) to allow only icmp echo request (ping), which is an icmp message number 8 and 0 between the two networks. When using predefined application called "ping" it allows other traffic and not just the icmp ping. I have also tried to create a custom application rule that would define icmp message number 8, but it does exact same thing as the predefined "ping". The rule would look like this:

When I run tcpdump or such utility on Zone2 host I see also TCP and UDP traffic. The firewall Monitor tells me that this is the rule that allows the other traffic. This could be a potential security issue?

We ran into this same problem. When you put 'PING' in the Application and leave the Source to 'any' it allows any TCP/UDP traffic. We are going to change the policy and see if 'default-application' fixes it. However, I agree that this is an issue. It is mis-leading to have a policy that states a firewall only allows PING traffic as the application on 'any' service, and yet allows ALL traffic.

Open Windows Defender Firewall and select Advanced Settings in the sidebar. Switch to Inbound Rules via the Getting Started page or the sidebar. Find the rule named "Core Networking Diagnostics - ICMP Echo Request (ICMPv4-In)" with Profile of "Private, Public" (unless you're on a corporate domain...). You can right-click the rule and Enable Rule.

This will automatically activate the appropriate rules in Windows Defender Firewall, e.g. File and Printer Sharing (Echo Request - ICMPv4-In). This will have the same effect as activating the rule Core Networking Diagnostics - ICMP Echo Request (ICMPv4-In) directly.

If you have McAfee, there's a setting under Firewall > My Network Connections > Edit to make your home router a "Home" network - the default is "Public," and McAfee will not accept ping (or many other net-tools) on Public networks.

I use NordVPN and have it configured on both the Windows 11 machine that prompted me to find this question, and on the Arch Linux machine which I was trying to ping it from. I performed some of the remediation steps described by other answers here, to no apparent result. Only once I considered the VPN configuration on the client, did I realize that might be the issue, and so I disabled the VPN on my Linux machine. This resolved the issue and allowed me to ping and otherwise connect to the Windows machine.

There is a setting in my VPN to specifically allow this sort of access, I won't note the name of the setting as it is specific to that VPN service, but there should be something referencing local network access in the settings of any decent VPN which may be required in order to utilize intranetwork ICMP and other connections while utilizing the VPN.

I'm coming from a Cisco ASA background and am finding the monitoring/logging on the UTM to be a bit difficult. On the ASA I could look a the syslog and see live monitoring of ALL traffic. Then filter accordingly.

The specific thing I'm looking for now is the ability to monitor pings (ICMP). Being as you have to set up ping in the firewall rules I'd think the firewall live log would be the place to look. Well I must be thinking wrong because it is showing neither successful nor non-successful ping traveling from the LAN to the WAN.

I've found that if I search the firewall log, using the search log files tab I can see ping info, but I need to see it live to perform debugging.

Can someone provide me some direction please?

Enabling PING through the ICMP tab does not enable "logging" of ping. I recently found out that you have to create a rule on the firewall tab for ping and enable logging on the rule for it to show up in the logs. You have three ways to enable PING. The Global ICMP Settings enable PING/Traceroute together. The PING Settings just enable PING, while the Traceroute Settings just enable Traceroute. You don't "need" to have both the Global ICMP and PING Settings enabled. Even with both of those disabled, you can create a firewall rule to allow ping with logging and a targeted source and destination.

I just tested and in order for it to show in the logs, it appears you have to have the "Global > Allow ICMP through gateway" and "Ping Settings > Gateway forwards pings" settings unchecked for the rule to log it. And you only get one entry per session, not per ping. To see another ICMP entry you have to wait for the session to timeout.

c01484d022