Hi @mhoam 

Thanks for posting in our business forum.

mhoam wrote

  @Clive_A 

 

Can you please confirm the default ACL rules applied to IPv6 packets in this beta release?

 

After updating to this firmware in order to implement security on my IPv6 connection, I am unable to establish an IPv6 connection to my ISP.

The IPv4 connection is working fine but the ISP is NOT seeing any DHCPv6 requests from my connection.

 

Thanks 

What kind of ACL Direction?

What's your ACL config scheme? Do you enable IPv6 in your involved LANs?

Please specify your issue clearly.

Note that all outgoing traffic should be fine as your devices initiate the connection which is not blocked by the NAT or firewall by default. Now, the traffic from WAN(IPv6) cannot initiate the connection to the LAN. This is a security improvement.
I also need you to identify the traffic flow and symptoms. If you can use the Wireshark to capture, let me know which direction and your symptoms.

Hi @mhoam

Thanks for posting in our business forum.

mhoam wrote

  @Clive_A 

Thanks for the prompt response.

I have NO ACL entries at all so far, for either IP4 or IP6

 

As you can see from the attached screen shot,  the outbound DHCPv6 connection is timing out. The "Solicit/Discover" timeout occurs a number of times and then the DHCPv6 process itself times out.

 

My ISP is a small organisatuion and I have talked to their technical team who have confirmed that they can see my IP4 connection, which is working correctly, but they detect NO IPv6 packets at all.

 

I believe I have configured the IPv6 LAN settings correctly, using SLAAC/RDNSS to distribute the IPv6 addresses and DNS servers to the clients.

 

If you say so, how do you configure your WAN? Is your ISP requiring dual-stack? I am confused. Please share more info instead of a screenshot of the log. It seems the WAN fails to conenct to their IPv6 server.

Hi @mhoam 

Thanks for posting in our business forum.

mhoam wrote

  @Clive_A 

Thanks for the response, I have ruled out the possibility that any implicit IPv6 ACL rules are causing my failue to connect via IPv6. I created a wide open (anything in and anything out) IPv6 ACL rule. This rule did not affect my issue so I have started to look elsewhere.

As you say, it looks like the Router Advertisment and DHCP Solicit packets are not reaching the ISP's servers for some reason.

 

Regarding your last comment that not all Omada routers support dual-stack IP, I am assuming that my ER605 DOES support dual stack (IP4 and IP6) transmission at the same time.

 

 

Please reply with the backup of your ER605. I'll send it over to the test team for reproduction. I reported it to the test team and they say they don't experience any issues with the IPv6 dialing.

Ticket number: TKID231111189

Hi @mhoam 

Thanks for posting in our business forum.

mhoam wrote

  @Clive_A 

In my original post, I asked about any default/implicit ACL rules for IPv6 in this beta release.

 

In a different thread, you replied to @cakemix with the comment :-

"Any incoming traffic is blocked by default settings when you upgrade to V2.2.2 or V2.1.5 beta. This was a security risk before so the dev patched this.

If you initiate an IPv6 connection, that should not be blocked at all."

 

So can you confirm that these releases (2.2.2 and 2.1.5) that implement an IPv6 Firewall via ACL rules also contain an implicit deny all for new incoming Ipv6 connections?

 

This sems to be the case as you can see from the attached screenshot from ipv6scanner dot com. This was taken before I created any IPv6 ACL rules.

 

 

This is a very sensible addition to the firmware, however can you ensure this important behaviour is documented in the Release Notes, in the latest version of the manual and in the in-built help behind the "?"

 

regards

mhoam

Supposedly, the firewall should block from WAN to LAN. Not from the LAN to WAN.

And this should be the way it is. And quite normal that this is blocked while the dev is working on implementing more IPv6-related stuff.

I am not able to confirm if this is achieved by an implicit rule in the ACL. But I can tell you this should be the way it is as the test team told me this is a security patch.

So I am confused if there are complaints about this. When there was no firewall, people were complaining IPv6 was dangerous. While we add this to secure the network, it becomes another complaint.

I am not sure why the dev did not add it to the note. I am not writing the release note because I am unaware of what the dev updates or not. But will report your concern to them.

Update:

Your OP is not the same thing. You are talking about the WAN to the ISP. This should be not blocked. If this is blocked, how do you even start a connection?

So, it is not about the ACL. I've sent it to the dev and waiting for a reply.

Test team told me that they using the same firmware in the lab environment and did not see any error like that. IPv6 dialing out works fine. You seem to be the only person now who runs into this error and WAN issue. I am also waiting for others to share their experience with this beta.