Re: Using API with Management Plane Sepration

Zoltan_Bogdan · ‎2022-02-11

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

Luis_Miguel_Mig · ‎2022-02-14

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.

Zoltan_Bogdan · ‎2022-02-14

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

Luis_Miguel_Mig · ‎2022-02-14

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

Zoltan_Bogdan · ‎2022-02-14

yes tried that as well made no difference.

Luis_Miguel_Mig · ‎2022-02-14

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

Zoltan_Bogdan · ‎2022-02-14

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.

_Val_ · ‎2022-02-14

I suggest a TAC case

Luis_Miguel_Mig · ‎2022-02-14

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.

Zoltan_Bogdan · ‎2022-02-14

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

_Val_ · ‎2022-02-14

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.

_Val_ · ‎2022-02-14

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

Zoltan_Bogdan · ‎2022-02-14

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

Robert_H · ‎2022-02-14

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

_Val_ · ‎2022-02-14

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

Robert_H · ‎2022-02-14

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

Zoltan_Bogdan · ‎2022-02-14

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.

Robert_H · ‎2022-02-14

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.

Zoltan_Bogdan · ‎2022-02-16

@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

Robert_H · ‎2022-02-16

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"

Robert_H · ‎2022-02-14

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.

Are you a member of CheckMates?

Using API with Management Plane Sepration