- CheckMates
- :
- Products
- :
- Quantum
- :
- Security Gateways
- :
- Re: orig_route_params kernel table
- Subscribe to RSS Feed
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Bookmark
- Subscribe
- Mute
- Printer Friendly Page
Are you a member of CheckMates?
×- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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
Accepted Solutions
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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).
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Appears to be related to SecureXL and VPN based on various SK articles.
I imagine it's a similar format to the connections table.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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]#
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
VPN is definitely handled in SecureXL.
Check fwaccel conns output and see if there are any matches for other IPs.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Got it, thanks!
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Might be worth a TAC case to investigate this more closely.
https://help.checkpoint.com
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Lets hope so...My understanding is also based on reading about it, it has to do vpn/sxl, but clarification would be nice.
Andy
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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).
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Thank you for the thorough explanation.
Regards,
Igor
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
![](/skins/images/74119E49EB1AA30407316FFB9151D237/responsive_peak/images/icon_anonymous_message.png)