Create a Post
cancel
Showing results for 
Search instead for 
Did you mean: 
imamuzic
Participant
Jump to solution

orig_route_params kernel table

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

 

0 Kudos
1 Solution

Accepted Solutions
PhoneBoy
Admin
Admin

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).

View solution in original post

16 Replies
PhoneBoy
Admin
Admin

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
Legend
Legend

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]#

0 Kudos
imamuzic
Participant

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. 

 

0 Kudos
PhoneBoy
Admin
Admin

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

0 Kudos
imamuzic
Participant

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. 

0 Kudos
the_rock
Legend
Legend

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

0 Kudos
imamuzic
Participant
0 Kudos
the_rock
Legend
Legend

Got it, thanks!

0 Kudos
PhoneBoy
Admin
Admin

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

0 Kudos
imamuzic
Participant

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. 

0 Kudos
the_rock
Legend
Legend

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

Andy

0 Kudos
PhoneBoy
Admin
Admin

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.

0 Kudos
PhoneBoy
Admin
Admin

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
Participant

Thank you for the thorough explanation. 

Regards,

Igor

 

0 Kudos
the_rock
Legend
Legend

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

0 Kudos
the_rock
Legend
Legend

his sk also may be helpful.

Andy

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

0 Kudos

Leaderboard

Epsum factorial non deposit quid pro quo hic escorol.

Upcoming Events

    CheckMates Events