Create a Post
cancel
Showing results for 
Search instead for 
Did you mean: 
Zoltan_Bogdan
Contributor

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

0 Kudos
20 Replies
Luis_Miguel_Mig
Advisor

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.

0 Kudos
Zoltan_Bogdan
Contributor

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

 

0 Kudos
Luis_Miguel_Mig
Advisor

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

0 Kudos
Zoltan_Bogdan
Contributor

yes tried that as well made no difference.

0 Kudos
Luis_Miguel_Mig
Advisor

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

0 Kudos
Zoltan_Bogdan
Contributor

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.
 

0 Kudos
_Val_
Admin
Admin

I suggest a TAC case

0 Kudos
Luis_Miguel_Mig
Advisor

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.


0 Kudos
Zoltan_Bogdan
Contributor

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

0 Kudos
_Val_
Admin
Admin

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.

0 Kudos
_Val_
Admin
Admin

After re-reading the tread, where is your authentication token? Check you login and reuse token before anything else.

 

0 Kudos
Zoltan_Bogdan
Contributor

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."
}

0 Kudos
Robert_H
Explorer

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

0 Kudos
_Val_
Admin
Admin

@Robert_H Interesting, I will need to double-check that...

0 Kudos
Robert_H
Explorer

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

0 Kudos
Zoltan_Bogdan
Contributor

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.

 

0 Kudos
Robert_H
Explorer

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.

0 Kudos
Zoltan_Bogdan
Contributor

@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

 

 

0 Kudos
Robert_H
Explorer

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"

0 Kudos
Robert_H
Explorer

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.

0 Kudos

Leaderboard

Epsum factorial non deposit quid pro quo hic escorol.

Upcoming Events

    CheckMates Events