- CheckMates
- :
- Products
- :
- Quantum
- :
- Security Gateways
- :
- Using API with Management Plane Sepration
- 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
Using API with Management Plane Sepration
Dear All,
I try to make IA-Api work with Management separation but although it appears to be handled by the multiportal daemon it is not accessible via management plane interface while Platform portal is.
I'm confused.
Thanks in advance
Zoltan
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Do you mean gaia api? Yeah, I have tested gaia api in the mgmt plane. https://mgmtip/gaia_api/command. Easy to test with postman and ansible too.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
nope, I'd like to get the Identity Awarenes Api working via management plane like this:
[root@zentos01 ~]# curl -k -H "Content-Type: application/json" -d $'{"shared-secret":"12345678",\n "ip-address":"192.168.0.11"}' https://192.168.3.27/_IA_API/v1.0/show-identity
{
"ipv4-address" : "192.168.0.11",
"message" : "total 0 user records were found."
}
But when turning mgmt plan on I get this instead:
[root@zentos01 ~]# curl -k -H "Content-Type: application/json" -d $'{"shared-sec ret":"Gb53Epg4RY",\n "ip-address":"192.168.0.11"}' https://192.168.3.27/_IA_API/ v1.0/show-identity
curl: (56) TCP connection reset by peer
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Do you have the api services configured in mdps? Like these two for example?
add mdps task process rest_api_docs
add mdps task process rest_api_run
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
yes tried that as well made no difference.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
I would suggest to take a network capture and see what port tries to reach and make sure that the port is configured like this
add mdps task port 80 protocol tcp
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Thanks for advice, but I'm not sure what I should sniffer for.
As stated above I call https://192.168.3.27/_IA_API/v1.0/show-identity on 443.
I've tried to add 443 the way you proposed but still got that connection reset.
Also tried to add different other things. I'm a little annoyed as I don't really understand how mdps really works and what it means to add one thing (service/port/application).
I suspect that IA-API is handled by the multiportal because I found some traces pointing there:
/opt/CPshrd-R80.40/conf/multiportal/httpd-conf/portalsPathPrefix.conf
[...] SetEnv MULTIPORTAL_IAAPI_PATH_PREFIX /_IA_API [...]
and in „$FWDIR/ICS/update/incoming/ICS.C
where i's stated that IA API is listening on
[...]:internal_port (8886)[...]
But neither am I able to see that port in netstat, nor is there any output sniffering on that port on loopback as I'd expect.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
I suggest a TAC case
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
If you are getting a "TCP connection reset by peer" I would filter those two ips 192.168.0.11 or 192.168.3.27 and try to find a TCP SYN and TCP RST.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Yes there is a reset, but what to do about it now?
I still have no clue how to get rid of it.
@ _Val_ Yes I'll go on an open an SR
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Basically, APIs are answering on the management IP address. If your management plane is configured properly, and MGMT interface is showing on the management plane, APIs should work. Check if clients are configured properly, but TAC is the fastest way, since you already tried some troubleshooting.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
After re-reading the tread, where is your authentication token? Check you login and reuse token before anything else.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Sorry, not sure what you mean.
The token is the shared Secret within the Post, isn't it?
And as long as mdps is off, it returns a valid respose.
[root@zentos01 ~]# curl -k -H "Content-Type: application/json" -d $'{"shared-secret":"12345678",\n "ip-address":"192.168.0.11"}' https://192.168.3.27/_IA_API/v1.0/show-identity
{
"ipv4-address" : "192.168.0.11",
"message" : "total 0 user records were found."
}
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Identity awareness API will not run on the management interface after data plane separation. IA API is handled by kernel API because all requests will be transferred to the kernel tables directly (performance).
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
@Robert_H Interesting, I will need to double-check that...
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Documentation sk138672 is not clear for that case.
As I understand, the first is kernel API, second is a httpd2 (portal API). I really don't know how it works internally because httpd2 is not responsible for IA API routing (but I would like to know).
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Would you please elaborate Kernel API or point me some documents? I never heard of that.
in the SK I only see this
- Access: SSH, FTP, and more
- Provisioning: Policy installation, Gaia Portal, REST API, and more
- Monitoring: Logs, SNMP, and more
with my IP_API probably subsumed under "more"
As I've found traces of IA-API in those files metioned above, I suspected that the whole thind is handled by the notorious multiportal daemon.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Sorry, I don't have any document or SK. This information was provided by our local SE. IMHO, it is logical, how IA API works. But we didn't find any related information on how IA API works when you have mgmt/data plane separation. TAC didn't help.
And from the real gateway: when you switch to dplane and try to find what process listen on port 443, the output will be empty. When you switch to mplane, your output looks like this:
[Expert@fw:mplane]# netstat -tnap|grep 443
tcp 0 0 0.0.0.0:443 0.0.0.0:* LISTEN 12740/httpd2
And when you try to telnet to port 443 on any interface from the data plane, gw will return what you need.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
@Robert_H those lines where copied from sk138672 you mentioned above.
Yes you're right, in mplane you can see httpd2 but I think this fact is rather distracting.
If I disable mplan and change the Gaia Portal to be listening to some bogus port 14345 that is reflecting in httpd2 as well while nothing seems to be listening in 443 anymore:
[Expert@CP8040-test:0]# mplane
Management data plane separation is disabled
[Expert@CP8040-test:0]# netstat -tnlp | grep 14345
tcp 0 0 0.0.0.0:14345 0.0.0.0:* LISTEN 19031/httpd2
[Expert@CP8040-test:0]# netstat -tnlp | grep 443
tcp 0 0 0.0.0.0:44309 0.0.0.0:* LISTEN 17924/fwd
tcp 0 0 0.0.0.0:44353 0.0.0.0:* LISTEN 17924/fwd
but nevertheless I am able to query IA-Api on 443:
[root@zentos01 ~]# curl -k -H "Content-Type: application/json" -d $'{"shared-secret":"Gb53Epg4RY",\n "ip-address":"192.168.0.11"}' https://192.168.3.27/_IA_API/v1.0/ show-identity
{
"ipv4-address" : "192.168.0.11",
"message" : "total 0 user records were found."
}
I suspect that this comes from the multiportald that is still listening on 443 but doesn't show up on netstat
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
I found it, its called IDAPI and it is a kernel module https://sc1.checkpoint.com/documents/R80.40/WebAdminGuides/EN/CP_R80.40_PerformanceTuning_AdminGuide...
You can troubleshoot it by the kernel debug command "fw ctl debug -m IDAPI"
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hi Zoltan,
We had the same issue 2 months ago. IA-API requests are handled directly by the kernel, not the apache process which is responsible for the Gaia portal. When you enable management separation, the kernel no longer listens o the management interface, and IA-API works only on the data interface.