ipv6 missing os route - RFx ?

[Jerry]

Hi Mates, got something unusual to you (at least I think it is unique but might be wrong). I cannot get a rid of the logs (stealth-wise) of following entries and R80.20 report them all the time in logs as dropped due to the "missing OS route".

What do you think? It is just misconcept of ipv6 route vs. nat64/46 or I'm just getting paranoid at some point?

Sorry if the entire ipv6 isn't your strongest point Im afraid I live with ipv6 with CP for a while now and each of my customer's plus myself privately uses ipv6 as "dual-stack" all the time so my ipv6 issues are either sporadic and serious or I'm sorting them out myself on-the-fly

Thanks for all the hints in advance. Here is the log record (should you need anyth. else - ask):

ps. bond1 is "internal-lan-interface" not WAN facing one.

Time: 2019-02-01T10:48:11Z
Interface Direction: inbound
Interface Name: bond1
Id: 01020301-e6bf-c920-5c54-23eb02ff0000
Id Generated By Indexer:true
First: true
Sequencenum: 4
Source: ::ffff:0.0.0.3
Destination: ::ffff:0.0.2.161
Destination Port: 3
IP Protocol: 6
Message Information: Missing OS route
Action: Drop
Type: Log
Policy Name: bla-bla-bla
Policy Management: cp
Db Tag: {52FA5790-CA72-A24C-A4A7-315A6C4DDFD4}
Policy Date: 2019-02-01T10:42:14Z
Blade: Firewall
Origin: cp
Service: TCP/3
Product Family: Access
Interface: bond1
Description: TCP/3 Traffic Dropped from ::ffff:0.0.0.3 to ::ffff:0.0.2.161

[Mark_Mitchell]

Hi Jerry, 

I'll be honest, IPv6 on Check Point is not my strongest point at the minute, this is something I intend to lab very shortly. However are the necessary routes present within Gaia for the destination host/network?

Might also be worth checking the Linux level routing table to see if the routes are present there. I believe you should be able to execute the "route" command from expert to see this.

Failing that I would suggest raising a TAC case to get this looked at. 

Regards

Mark

[Jerry]

Thanks Mark. Indeed it is one of the options. I do appreciate your reply.

Let's see what I can do about TAC SR/. In the meantime I'll try to find out whether the routes towards that 'unknown' subnets are actually possible to handle by blackholing to my honeypot or simply re-route somewhere.

Although I do believe that there is something wrong on the ipv6 stack with ‌ and I think I found something interesting out there which may clarify me being paranoid. Also in terms of the routing itself I do use ipv6 only internally on that gw hence my frustration with regards to the traffic passers (ipv6 packets out of the blue) which aren't anywhere configured on my net. That's why it is so wired as I do not use any of those IPs anywhere within the infrastructure.

Maybe now I have managed to clarify that at least a little here.

Cheers again and hope to see from you soon

J.

[Jerry]

I think I found the problem  

have a look: https://en.wikipedia.org/wiki/Reserved_IP_addresses

I believe one of my SGs is taking the mapped ipv6 multicast from mapped ipv4 address hence that traffic  mapping with new R80.20 nat64/nat46 does not yet mattured though  

[Jerry]

sorted by adding ::ffff:0:0:0/96 to the Security Policies (Stealth one) for IN and OUT.

NO more packets from mapped ipv6 nat46 addresses out
Also, look at the default gaia clish config of:

set ipv6 inbound-route-filter ospf3 instance default accept-all-ipv6

- that is very much the root cause of the packets for kernel ipv6 nat floods.

@TAC - should you want or have a time for t-shooting that please let me know. I'm happy to be ipv6 lab rabit if y

[Mark_Mitchell]

Hi Jerry,

Really glad you managed to find the solution to your problem, and thanks for sharing your solution. 

Definitely something I am going to lab.

Regards

Mark