- Access exclusive content
- Connect with peers
- Share your expertise
- Find support resources
05-15-2019 01:19 AM
We have two PA's connecting to one ISP. One is just being set up.
The ISP is "10.10.10.0/27"
Route is "10.10.10.5"
Is it correct to have both firewall external vlan interfaces as such
FW1 "10.10.10.99/27"
FW2 "10.10.10.122/27"
Vlan 140
And for the NAT
FW1 Main Nat "10.10.10.99/27"
FW2 Main Nat "10.10.10.122/27"
I ask, because the new firewall is logging packets for the old firewall. I am seeing "x.x.x.99" on the firewall with VIP "x.x.x.122"
05-15-2019 01:33 AM
- If your ISP's subnet is 10.10.10.0/27 , you have usable IP addresses 10.10.10.1 to 10.10.10.30, so your firewalls would need to have an IP in that range
- your vlans are untagged, you'll want to tag them and use proper vlans on your switches to prevent having one giant, and insecure broadcast domain
are there any other nat rules? it's possible your old firewall has taken ownership of all the IP's in that subnet if there's a NAT policy that allows it
05-15-2019 01:49 AM
The IP's were just an obscured example.
Both have the same "/27" on the interface and is that correct?
Neither firewall has overlapping NAT IP addresses. the NAT addresses are x.x.x.y/27
I have the VLANS tagged on the aggregate interface, I assume that is sufficient and does not need tagged on the VLAN aswell. The switches are VLANED.
05-15-2019 01:54 AM
It all seems to be working,
It's just the loggs showing IP's from the other firewall that are the concern. There's a 3rd Device on that subnet that also connects to the ISP, I don't see it at all in the loggs.
05-15-2019 08:43 AM
Hello,
Are you running active/passive or active/active? A/P doesnt need an IP for each firewall as they are shared between the two.
Regards,
05-15-2019 08:50 AM
Two independant firewall HA stacks, one ISP Subnet.
05-15-2019 12:15 PM
Hello,
My guess is that you have a policy somewhere that allows the 'untrust' zone to 'untrust' zone traffic and its set to log. This will catch any traffic that the interface picks up on.
Regards,
05-16-2019 12:53 AM
"Intrazone-Default" is set to log as per Palo Best Practice.
I will stop worrying about it as I thought the configuration was correct and there are no issues.
05-17-2019 01:05 PM - edited 05-17-2019 01:09 PM
May I ask why you are using VLAN interfaces to begin with? I avoid this if at all possbile. I would recommend using sub-interfaces at Layer 3. It is easier to manage, easier to read and makes your zone/ruleset clean. If you're not transporting Layer 2 traffic through the firewall, VLAN interfaces are almost unnecessary. Thoughts?
Lab Example -
05-20-2019 01:51 AM
TBH never realy thought about it too much, It was how our original firewall was configured and how I have built things in the test labs. Can't even reember how we did it during the training course.
I can see it's a bit cleaner having converted it all over.
Not even sure why I did not twig it was a possibility as I am running a L3 single interface at the moment to the outside world
05-27-2019 10:54 AM - edited 05-27-2019 10:56 AM
It's easy to get confused by Palo Alto's various uses of VLAN.
A "VLAN" interface is different from a "Layer 3" interface that has 802.1q vlan tags enabled.
On a PA device "VLAN" interfaces are used to create a virtual switch using ports on the firewall, and allow them to operate as layer 2 interfaces without routing abilities. Essentially, it create a bridged interface using all the VLAN interfaces.
If you want to enabled tagged (or untagged) 802.1q vlans on interfaces, then configure them as "Layer 3" and create sub-interfaces with the vlan tag set there.
Would be nice if PA updated their UI to remove the ambiguous and confusing "VLAN" interface type. "Bridge" would be more accurate.
05-28-2019 06:23 AM
I couldn't agree with you more. This really confused me the first time I used PAN and the documentation explaining this wasn't great.
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!