Cannot access HTTPS sites using non standard ports

Announcements

ATTENTION Customers, All Partners and Employees: The Customer Support Portal (CSP) will be undergoing maintenance and unavailable on Saturday, November 7, 2020, from 11 am to 11 pm PST. Please read our blog for more information.

Reply
Highlighted
L4 Transporter

Cannot access HTTPS sites using non standard ports

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

 

ND.jpg

1.jpg


Accepted Solutions
Highlighted
L4 Transporter

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.

 

View solution in original post


All Replies
Highlighted
L3 Networker

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

Highlighted
L7 Applicator

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

 

 

 

Tom Piens - PANgurus.com
New to PAN-OS or getting ready to take the PCNSE? check out amazon.com/dp/1789956374
Highlighted
L4 Transporter

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.

Highlighted
L2 Linker

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 ?

 

Highlighted
L4 Transporter

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:

 

TrafficLog.jpg

Highlighted
L7 Applicator

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?

Tom Piens - PANgurus.com
New to PAN-OS or getting ready to take the PCNSE? check out amazon.com/dp/1789956374
Highlighted
L4 Transporter

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.

Highlighted
Cyber Elite

@Farzana,

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. 

Highlighted
L4 Transporter

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.

 

View solution in original post

Like what you see?

Show your appreciation!

Click Like if a post is helpful to you or if you just want to show your support.

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 Live Community as a whole!

The Live Community thanks you for your participation!