Internal traffic is hitting in the isp firewall

cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 
Announcements
Please sign in to see details of an important advisory in our Customer Advisories area.

Internal traffic is hitting in the isp firewall

L2 Linker
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.
17 REPLIES 17

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?

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

 

 

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.

 

 

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.

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.

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

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

L2 Linker

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

****************************************************
ACE 7.0, PCNSE7

Yes

There is no possibility for VLAN bleeding on your switch perhaps? (where the internal vlan can communicate to your external vlan because someone made a bridge with a cable or something, or connected a 2nd switch with the vlans not properly defined)

 

you could try investigating by seeing if you connect a host to the external vlan, in the IP range of the internal network, and then seeing if you can get ARP replies and ping replies

then check on your switch if you can trace where the MAC addresses get registeren, then verifying if the physical ports on your switch correspond to where they should be connected (is the mac seen on the physical port connected to the firewall or elsewhere, or multiple places perhaps)

 

meanwhile you can verify on the firewall with 'show session all filter source x.x.x.x destination y.y.y.y' if the session is flowing through the firewall or not

 

Tom Piens
PANgurus - Strata specialist; config reviews, policy optimization

Not sure if I'm properly understanding the issue or not... is it that you're just seeing internal IP addresses hitting the ISP edge?  Is it traffic with a destination IP outside your network (i.e. on the Internet)?  If so, have you confirmed that you have a NAT policy set up for that traffic?

 

I've had this happen a few times to me and usually it was due to me missing a NAT policy when setting up the new firewall config based on our old one.  Internal traffic followed the default route to our untrusted side (assuming, of course, that we didn't have a more specific route pointing it somewhere inside) and without the NAT policy it continued on as an internal IP until an upstream device dropped it due to an invalid private source IP.

 

If the destination IP is something that should be on your internal network, it could that there isn't an installed route that matches so, again it follows the default route towards your ISP and, without NAT, shows up as an internal IP.

Hi All, thanks for suggestions.

 

ISP report attached below: source and destination details

 

when i filter the below logs in traffic logs, i can see the below session in firewall

But it was going to someother interface, not going to ISP interface. However ISP report inlcudes below session details.

 

Routing is proper, there is no NAT involved.

 

q-forum.PNG

Its possible VLAN bleeding on the switch. Thanks for suggestion.

 

But anyway traffic should not go to ISP interface as any zone to ISP zone is denied in policy and logging also enabled.

Can you please post the firewall session logs for the above mantioned ip`s?

If the sessions are leaving the firewall and the next hop or egress interface not the one that is facing the ISP, them you need to check that device. 

 

p.s no need to hide the ip`s as they are private anyway 😉

qcc99.png


@TranceforLife wrote:

Can you please post the firewall session logs for the above mantioned ip`s?

If the sessions are leaving the firewall and the next hop or egress interface not the one that is facing the ISP, them you need to check that device. 

 

p.s no need to hide the ip`s as they are private anyway 😉



@TranceforLife wrote:

Can you please post the firewall session logs for the above mantioned ip`s?

If the sessions are leaving the firewall and the next hop or egress interface not the one that is facing the ISP, them you need to check that device. 

 

p.s no need to hide the ip`s as they are private anyway 😉


 

  • 6516 Views
  • 17 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!