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 

[imamuzic]

TAC brought me here actually 🙂 because we have an issue covered probably by sk180956, I asked 2 times TAC engineer why the issue is related to IPSec NAT-T and what is the purpose of the "orig_route_params" table and got 0 answers, so I was forced to investigate it by myself and so far concluded that this must be related to SecureXL IKE session acceleration and IPSec acceleration, but since SecureXL handles TCP/UDP only and NAT-T encapsulates ESP into UDP it must be why this SK is about NAT-T, although I'm confused a little bit because SecureXL actually accelerates ESP packets too...

So, this is why I came here hopping someone (from R&D perhaps) will clarify the sk180956 and "orig_route_params" table to me. 

[the_rock]

Lets hope so...My understanding is also based on reading about it, it has to do vpn/sxl, but clarification would be nice.

Andy

[PhoneBoy]

It's definitely related to SecureXL and VPN based on the various SKs and SRs I looked at.
I'll see if I can get an answer from someone in R&D about it.

[PhoneBoy · Accepted solution]

orig_route_params maps the routing information (inbound interface, next-hop-router L2 addr) and the NAT-T source port to  how the NAT-T packet entered the gateway from the peer.
This is done so the gateway can send reply with same routing the packet as entered, and with peer’s current NAT-T port.
This applies for both Site-to-Site with DAIP gateways and Client-to-Site VPN.

So what’s in it?
The keys are the OM IP and user md5 in case of Endpoint. In case of DAIP the key is the DAIP ID.
The values including the port and the routing data (in kbuf as it includes the MAC address).

[imamuzic]

Thank you for the thorough explanation. 

Regards,

Igor

[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