URL Access Failed

[Matlu]

Hello,

I need to allow access to a URL to a particular IP.
I have separate Firewall+APPC&URLF layers.

I have rules allowing access on both layers.
I have also "Bypassed" at HTTPs Inspection level the page to consume, but the problem of the IP to access the domain, still remains.

At the log level, I don't see a log like Drop or Reject, rather, it seems to be all right, as it shows that the flow is "allowed".

The URL to which the user wants to access is https://apps2.mef.gob.pe/siafmib/

Is there a way to make a good filter at LOGS level that allows me to confirm, if the GW is really blocking or not the connection to the IP?

Source: 10.192.116.59
Destination: https://apps2.mef.gob.pe/siafmib/

Thanks for any comments.

[the_rock]

If you alow it on both ordered layers, then policy should not be blocking it. Do you use https inspection on the gateway(cluster)?

Also, if logging works, then you can either filter by ip or simply fqdn itself or you can try resource:fqdn, ie resource:www.news.com

Kind regards,

Andy

[Matlu]

Hi, Andy,

Yes, the GW has HTTPS Inspection enabled.

The problem is, the user can access the URL https://apps2.mef.gob.pe/siafmib/ .... but when he is already in the portal, here he must enter some credentials to access the final resource, but when he enters the credentials and presses "ENTER", the page stays "thinking", and fails to load.

A query, if the ORIGIN that wants to consume this URL, does not have the HTTPS Inspection certificate installed, can you have these access problems?

Greetings.

[the_rock]

Can you send a screenshot of how you made https inspection bypass?

Kind regards,

Andy

[Matlu]

In the logs of the IP that we need the URL to consume, we find a "log" related to the HTTPS Inspection part.

Forget to completely check if the IP that needs to access the URL, had or had not installed the certificate on your PC, we validated and did not have the certificate installed, we installed it and now if you can access that portal.

[the_rock]

As @Wolfgang said, screencap of the rules would be helpful.

Regards,

Andy

[Chris_Atkinson]

Do I misunderstand or is the issue now resolved?

Address spoofing typically implies something different...

[Matlu]

Hello

Does address spoofing usually indicate that something is wrong with the firewall?

Is it something to take into account?

Or normally why does this kind of logs appear?

Cheers.

[Chris_Atkinson]

Firstly it is a "Detect" not a "Prevent" (drop) log 

Commonly this (address spoofing) would infer traffic is seen on an interface from which the origin doesn't belong and may be indicative of a routing problem or other issue.

Please clarify if the original issue still persists?

[Matlu]

The problem that I exposed has been corrected.

It turns out that the client is using HTTPS Inspection in the GW.

For some reason the client was able to access only to the portal of the subdomain that I exposed at the beginning "https://apps2.mef.gob.pe/siafmib/" ... but when he entered his login credentials, the web remained "thinking".

This was solved, once the client on the affected PC, installed the HTTPS Inspection certificate.

Can not having the certificate installed on the clients (PCs) cause problems like this?

I clarify that the problem was only at the time of "logging" the credentials on the web, the certificate, fixed this.

[Wolfgang]

A look at your rules would be very helpful. If you don‘t use HTTPS inspection on your gateway you can‘t filter the URL. The first request for your shown URL will be encrypted and can‘t be seen by the gateway. You can create an accessrule with „.apps2.mef.gob.pe“ as FQDN destination but not the whole URL.

[_Val_]

URL above is not working even without a FW, so it's hard to tell.

[the_rock]

I believe its internal site based on the link itself...

Andy