RESOLVED: IPv6 and ICMP packets with UTM

Hi xnsys,

It's true, that ping packets are allowed, if you enable "Gateway forwards trace route". It has technical reasons and is documented in the Onlinehelp:
"Note – If enabled, the traceroute settings also allow ping packets, even if the corresponding ping settings are disabled."

I'm not sure if I understand the problem with "Allow ICMP through Gateway from external networks". If you select and apply the option, you allow ICMP packets going through interfaces with default gateways. (the interface must be the incoming interface)
If you don't select the option, you can't send ICMP packets through interfaces with default gateways.

At least one of the following options must be enabled so that "Allow ICMP through Gateway from external networks" works:
* Allow ICMP through gateway
* Gateway forwards pings
* Gateway forwards traceroute

/Daniel

The problem is not ICMP packets going from the LAN to WAN, it's the other way round.

It works fine for IPv4, but not IPv6.

The firewall is allowing LAN machines to be pinged from the WAN, despite unchecking the "Allow ICMP through Gateway from external networks" option - surely this would mean that internal machines are not visible to ICMP?

If you have any other option ticked, then there is no change in function with the "Allow ICMP through Gateway from external networks" option - it will always allow packets from the WAN to LAN via IPv6.

I tried the "Allow ICMP through Gateway from external networks" option in combination with " Allow ICMP through gateway" and "Gateway forwards pings" and it works as expected for me.
Whenever I unchecked "Allow ICMP through Gateway from external networks" the ping6 packets are not forwarded from WAN to LAN anymore.

Could you show / explain how your Interfaces are configured? Where are your icmp6 packets come from and where do they go?

I only have 2 interfaces, external PPPoE and Internal.

It's a very simple set-up with the UTM acting as a perimeter firewall.

I only have 2 interfaces, external PPPoE and Internal.

It's a very simple set-up with the UTM acting as a perimeter firewall.

I really cannot reproduce your issue. :/
Could you open Webadmin and go to Logging & Reporting >> View Log Files and check, if you find any errors in the MiddleWare?

I just checked if the ip6tables rule is written for a PPPoE interface and it worked. Do you have ssh access to your machine? Maybe you could verify, if the iptables rule is present for you as well.
Just disable "Allow ICMP through Gateway from external networks" and enable "Gateway forwards pings".
Connect to your UTM via ssh and execute this command:
# ip6tables -vnL AUTO_FORWARD

You should find a DROP rule pinned to a ppp device (e.g. ppp0).

Just got loads of this repeated in the middleware logs - nothing that looks like an error to me.

2016:02:26-08:36:10 phobos middleware[3782]: T main::top-level:275() => cycle 838 waiting for 1 children
2016:02:26-08:36:30 phobos middleware[3782]: T main::top-level:264() => ending cycle 838, caught 1 signals, 1 children still running
2016:02:26-08:36:30 phobos middleware[3782]: T main::top-level:213() => starting cycle 839, caught 1 signals
2016:02:26-08:36:30 phobos middleware[3782]: T core::Config::Changed:194() => configversion=937
2016:02:26-08:36:30 phobos middleware[3782]: T core::Config::Changed:204() => nodes=0 objects=1 triggers=0
2016:02:26-08:36:30 phobos middleware[3782]: T core::Config::load:347() => modules=2,10
2016:02:26-08:36:30 phobos middleware[3782]: T modules::up2date::load:108() => amazon_deployment_type=
2016:02:26-08:36:30 phobos middleware[3782]: T modules::up2date::setAll:240() => up2date setAll
2016:02:26-08:36:30 phobos middleware[3782]: T modules::ipset::deleteUnused:320() => auto#=3/682 confd#=1/341
2016:02:26-08:36:30 phobos middleware[3782]: T main::top-level:275() => cycle 839 waiting for 2 children
2016:02:26-08:36:32 phobos middleware[3782]: T main::top-level:275() => cycle 839 waiting for 1 children

Result of  ip6tables -vnL AUTO_FORWARD

Chain AUTO_FORWARD (1 references)

 pkts bytes target     prot opt in     out     source               destination         

    0     0 STRICT_TCP_STATE  tcp      *      *       ::/0                 ::/0                 ctstate INVALID,NEW

    0     0 CONFIRMED  icmpv6    *      *       ::/0                 ::/0                 ipv6-icmptype 128 code 0

    0     0 CONFIRMED  icmpv6    *      *       ::/0                 ::/0                 ipv6-icmptype 129 code 0

Just checked again, disabled the windows firewall on the local machine, with Allow ICMP through Gateway from external networks enabled, ICMP doesn't reach the internal machine, with Gateway forwards pings enabled, the local machine receives the packets, and responds to ICMP.

Hi xnsys,

If you have "Allow ICMP through Gateway from external networks" enabled, you explicitly allow ICMP traffic from external to internal networks. To forbid this you have to uncheck "Allow ICMP through Gateway from external networks" and you have to enable "Gateway forwards pings" for example. Then the DROP rule should be written.

You described the correct behavior with both enabled: "Allow ICMP through Gateway from external networks"  and "Gateway forwards pings".

/Daniel

I'm confused - surely with "Allow ICMP through gateway enabled, there should be no WAN to LAN ICMP, as described in the help "Allow ICMP through gateway will make the system forward ICMP traffic if originating from an internal network.."

These are the results per different configuration of the ICMP section - does this seem correct to you?

Result:

Configuration: -

Result: -

Configuration: 

Result: 

Configuration

Result

And even more strange.....

Surely with all these options deselected I shouldn't be able to ping an external IP from internal?

Regards

Tim

You are right. With your last two pictures you should only be able to ping from the UTM itself but not through the UTM from internal to external.

Do you have any firewall rules configured in Network Protection >> Firewall >> Rules?

Those could match ICMP traffic as well, if you don't explicit allow the traffic in the ICMP tab.

Regarding the second to the last post:

Could you do me a favor and provide me the output of the following commands for the "reachable" cases?

# ip6tables -vnL AUTO_FORWARD

# cc get icmp

I assume you tried to ping from external to internal, right?

Thanks a lot!

/Daniel

I do have a any internal to any external rule - guess that's picking up ICMP - but I would have thought that the firewall would have applied the ICMP rules first??  Maybe inthis case it's not.

All results where I'm told that it's either reachable or filtered are from external to internal

I did create a from external to internal drop ICMP for IPv6 rule, that also made no difference, the settings in the ICMP tab overruled what was in the firewall settings.

This is the ip6tables -vnL AUTO_FORWARD results, with just  Allow ICMP through gateway selected.

This is the cc get icmp results

With Gateway forwards pings selected only.

And with only the "Allow ICMP through Gateway from external networks" option selected.

The options in the ICMP tab overrule the firewall rules in Network Protection >> Firewall >> Rules. But if you uncheck the options in the ICMP tab there are no rules for ICMP anymore on the system which means the firewall rules could match the traffic.

Is it possible to get ssh access to your machine? That would be really helpful and would speed it up. :)
Unfortunately I can't reproduce your issue and the packetfilter rules should contain a DROP rule which isn't the case for you.

For me it looks like this on the shell (with eth0 as default gw):

Thanks!

/Daniel

Just thought I would try something out the box.

Took a copy of the config for my UTM, built a new isolated VM and restored the configuration - still getting the same results as I was previously.

Changed the external interface from PPPoE to Ethernet, and voila - getting the drop ICMPv6 eht0 rule - changed back to PPPoE and it's gone!

So this looks like it's a PPPoE bug.

I opened a ticket for the issue.

Thanks a lot for the effort and the patience! [:)]

Would it be possible to get ssh access for debugging next week?

/Daniel