Internal traffic is hitting in the isp firewall

[Javith_Ali]

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.

[TranceforLife]

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?

[Javith_Ali]

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

[Javith_Ali]

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.

[TranceforLife]

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.

[Javith_Ali]

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.

[TranceforLife]

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:

[Javith_Ali]

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

[ChrisRussell]

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

[Javith_Ali]

Yes

[reaper]

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

[jsalmans]

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.

[Javith_Ali]

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.

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.

[TranceforLife]

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 😉

[Javith_Ali]

---

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

---