- Access exclusive content
- Connect with peers
- Share your expertise
- Find support resources
12-05-2017 07:40 PM
Hello,
When we switch the connection to a 4G connection, was able to connect to the URL without any issues:
wget https://www2.medicareaustralia.gov.au:5447/ --no-check-certificate
--2017-12-06 10:39:16-- https://www2.medicareaustralia.gov.au:5447/
Resolving www2.medicareaustralia.gov.au... 203.80.58.18
Connecting to www2.medicareaustralia.gov.au|203.80.58.18|:5447... connected.
Through PA, we are getting below:
wget https://www2.medicareaustralia.gov.au:5447/ --no-check-certificate
--2017-12-06 10:21:30-- https://www2.medicareaustralia.gov.au:5447/
Resolving www2.medicareaustralia.gov.au... 203.80.58.18
Connecting to www2.medicareaustralia.gov.au|203.80.58.18|:5447... failed: Connection timed out.
Tried using a simple test rule from Inside to Outside, Application any, Service/URL Category any, without any profile.
No NAT in use.
No-decrypt rule is in use for URL category: *.gov.au
12-12-2017 04:40 PM
Thank you all for the suggestions. Really helpful.
Client found out there was another set of firewall by the Upstream provider that caused the issue.
12-06-2017 12:02 AM
Can we see the Security policy Rule
are you using app default or a specific service (serivice-http, service-https)
is it being identified in the traffic log as SSL
or something else
12-06-2017 02:12 AM
your log states the app is incomplete and there's only 1 packet sent, none received
you may want to do some more basic troubleshooting like a ping or traceroute to verify if your routing is letting you get to the server, and then perform more tests to see why you are not receiving a reply packet (is the conenction being NATed, is the port allowed to pass through the upstream router, is the destination server blocking your ip,...)
12-06-2017 12:49 PM
Have you modified these to use your custom port: service-http, service-https? If not, then you are blocking the traffic. Those two default to port 80 and port 443. You need to create a custom service and set the port in there, then assign that service to your Security Policy.
If you check the Monitor tab, you'll see your traffic listed with "action = deny", with the ports listed in there.
12-06-2017 01:30 PM
Hello Farzana,
Agree with another comment here: your log shows that the flow is seen as incomplete with no ingress packets. I would assume a network architecture problem like assymetry or a NAT problem: you tell that there is no NAT policy configured... Even an outbound one ?
12-06-2017 05:21 PM
This issue only occurs when using a non-standard port 5447.
The Security policy is a simple one with application and service set to Any.
As mentioned earlier, no NATTing is there.
If I go to URL https://www2.medicareaustralia.gov.au/
I do get a response back from the Server, as shown below:
12-06-2017 11:44 PM
hi @Farzana
your outbound packets are being passed along so my guess would be there is an upstream issue
Since you're not applying NAT on the Palo Alto, is your upstream NAT device perhaps configured to NAT default ports (80+443) and not 'high' ports?
12-07-2017 08:37 AM
Can you show your "Pinterest Allow" Security Policy? That's the one that's matching the traffic, as shown by the log entries. And show the Security Policy that you think it's supposed to be matching.
12-07-2017 09:30 AM
The current traffic is being allowed through the "Pinterest Allow" security policy, and prior traffic was being allowed through your test rule. Since your only test of this actually working is through a 4G connection, was that done through your Palo Alto or on a mobile device.
I think @reaper is right, this looks like it's an issue upstream from your Palo Alto. With the information provided I would start testing to see if you can access the site through the ISP connection if you bypass the PA all together, my initial guess would be that this test will fail. Once you've verified it's an ISP issue, then you can start the process of troubleshooting with the ISP.
12-12-2017 04:40 PM
Thank you all for the suggestions. Really helpful.
Client found out there was another set of firewall by the Upstream provider that caused the issue.
Click Accept as Solution to acknowledge that the answer to your question has been provided.
The button appears next to the replies on topics you’ve started. The member who gave the solution and all future visitors to this topic will appreciate it!
These simple actions take just seconds of your time, but go a long way in showing appreciation for community members and the LIVEcommunity as a whole!
The LIVEcommunity thanks you for your participation!