Re: orig_route_params kernel table

imamuzic

Hello,

I would like to know what is the kernel table "orig_route_params" used for? I understand it is basically ARP table for SecureXL, but when I open it I only see IP addresses in hex format and IP address of one of the gateway's interfaces. How to interpret this table?

Regards,

Igor

PhoneBoy

Appears to be related to SecureXL and VPN based on various SK articles.
I imagine it's a similar format to the connections table.

the_rock

You can try below and see what you get.

Andy

[Expert@CP-GW:0]# fw tab -f -t orig_route_params
Using cptfmt
Formatting table's data - this might take a while...

localhost:
Date: Jul 30, 2024
13:44:28 5 N/A 3 172.16.10.249 > N/A LogId: <max_null>; ContextNum: <max_null>; OriginSicName: <max_null>; : (+)====================================(+); Table_Name: orig_route_params; : (+); Attributes: dynamic, id 442, attributes: keep, sync, kbuf 1, expires never, , hashsize 16384, limit 10200; LastUpdateTime: 30Jul2024 13:44:28; ProductName: VPN-1 & FireWall-1; ProductFamily: Network;
[Expert@CP-GW:0]#

imamuzic

Yes, but what these IP addresses represents? In my output some of them are known IKE peers, but some of them are public IP addresses that are non existent neither as objects or log entries.

PhoneBoy

VPN is definitely handled in SecureXL.
Check fwaccel conns output and see if there are any matches for other IPs.

imamuzic

I've found only one match between SecureXL (fwaccell conns) and "orig_route_params" table and this is an IP address of another IKE peer. All other IP addresses found in the "orig_route_params " table are either local or remote IKE peers or public IP address I'm unable to reference to neither Interoperable objects or Gateways.

I would conclude that these unrelatable addresses are in the table because these are about unknown IKE end points attempting unsuccessful IKE negotiation with the gateway, but then how come that there is no Log record about this?

Without these unrelatable addresses in the table I would conclude that this table simply stores IP addresses of either local or remote IKE Check Point locally managed peers as these are SecureXL acceeleated IKE sessions, while 3rd party VPN peer's IKE sessions are handled by IKE VPN deamon and therefore should not be seen in the "orig_route_params" table, at least I figured so from Timothy_Hall's post on similar subject.

the_rock

Thats actually a good point, I saw the same in my lab and Azure lab as well, but could not see any logs for it either.

@imamuzic Whats the link to Tim's post about it?

Andy

imamuzic

Here you go: https://community.checkpoint.com/t5/Security-Gateways/Problem-with-MAC-address-on-the-wrong-interfac...

the_rock

Got it, thanks!

PhoneBoy

Might be worth a TAC case to investigate this more closely.
https://help.checkpoint.com

the_rock

Sorry mate, totally forgot to test this today. Let me set up bogus VPN community and run the command again and I will update shortly.

Apologies again.

Update...ran the command after creating test vpn community and it showed the IPs there. I will run it again in the morning.

Andy

the_rock

his sk also may be helpful.

Andy

https://support.checkpoint.com/results/sk/sk116453

Are you a member of CheckMates?

orig_route_params kernel table