Cannot access HTTPS sites using non standard ports

cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 

Cannot access HTTPS sites using non standard ports

L4 Transporter

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

1 accepted solution

Accepted Solutions

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

9 REPLIES 9

L4 Transporter

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

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 - Strata specialist; config reviews, policy optimization

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.

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 ?

 

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

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 - Strata specialist; config reviews, policy optimization

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.

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

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.

 

  • 1 accepted solution
  • 9458 Views
  • 9 replies
  • 0 Likes
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 LIVEcommunity as a whole!

The LIVEcommunity thanks you for your participation!