Internal traffic is hitting in the isp firewall

Reply
Highlighted
L2 Linker

Internal traffic is hitting in the isp firewall

Palo alto is perimeter to customer which is connected to isp firewall.

Internal subnet traffics which are not allowed in isp/ untrust interface are hitted in isp firewall.
Routing is proper. ARP is proper in isp interface( only next hop arp is there)

Implicit deny policy blocking the interzone traffic trust to untrust.

We don't have any clue how our internal private ip address communication is going to ISP firewall.

There is no allowed security policyfor reported internal ip's and routing is proper.
Highlighted
L6 Presenter

Do you have logs showing the same? Do you know if the course of the traffic is the client(s) ip addresses or actually firewall itself?

Highlighted
L2 Linker

Thanks for reply.

 

there is no logs showing for the same(means internal to Untrust).

 

However i can see the logs for the same reported IP's from trust to DMZ subnet (it is taking the actual route configured in VR).

 

we are getting the report from ISP on Weekly basis. ISP is sharing the different IP's (on weekly basis) but same source subnet (trust) and destination subnet (DMZ).

 

These IP's are not configured in firewall. client IP's only. Please suggest

 

 

Highlighted
L2 Linker

 

we have tried to configure the pcaps filter from trust to untrust subnet   (which should not be allowed and routing also not there).

 

But we can filter using ingress interface only. There is no option for egress in pcaps.

 

So we dont want to configure above filter for reported subnets as this will capture whole legitimate traffics  going to DMZ as well.

 

 

Highlighted
L6 Presenter

Ok. Do you have log enable on the policies so you can confirm if that traffic is actually traversing the firewall and not taking the "alternative" route? Logs will be generated as soon as the traffic is passing the firewall. Logs will not be generated if the traffic is not passing the firewall or for the traffic generated by firewall itself.

Highlighted
L2 Linker

we have enabled the log at session end in implicit deny policy last week. prior to that logging was not enabled. it will useful to find out RCA.

 

But this traffic should be blocked by implicit deny policy.

Highlighted
L6 Presenter

Confirm with ISP the time of the new logs then check your source & destination ip logs on the firewall. If you will not be able to find any then the traffic is not passing the box. For even better visibility l also would suggest you to override the default intra & inter deny policy by enabling the log function:

 

over.PNG

Highlighted
L2 Linker

Thanks for suggestion.

 

If we find this abnornal traffic to untrust ISP interface gets logged in firewall, then probably ARP in ISP interface would be the problem i think. Is there any other possibility

Highlighted
L2 Linker

You are 100% sure all the traffic is routed through the Palo? 

****************************************************
ACE 7.0, PCNSE7
Highlighted
L2 Linker

Yes
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!