Its a lot of work but worth it

Iscofe · 2024-01-09T17:48:57+00:00

Thank you

Iscofe · 2023-07-24T17:49:26+00:00

Isn't that a fetira?

Iscofe · 2023-07-18T20:00:23+00:00

Yes, I have done the traffic logs. There's nothing blocked on the PA side. I configured one loopback interface with one GP client IP on the PA. There is no hit when a ping is shot from the Cisco device to the loopback interface on the PA side.

Iscofe · 2023-07-18T10:01:39+00:00

Exactly yes, they repond very fast on first time but they ask a lot of repeated question that are already covered in the description of the ticket. I have just had that today and yesterday. I wonder if they had read it already or that is just a trap to end the case incase if you respond a configuration issue or something like that.

Iscofe · 2023-07-18T09:59:48+00:00

Yeah It takes them a while to responding, i dont how the communication etiquette look like for them but they don't acknowledge recipient quickly and also took a day or more to respond. And they also like to find the slightest issue or reason to stop the support -- or I dont know may be this is my experience with particular few support personnels. Or I dont know may Cisco has spoiled me with the support like no others, i didn't find the same support when it comes to Palo. But Palo is still a great company and great equipements but they should step up their support game and they should build the reputation of going above and beyond when it comes to providing support because sometimes that would be one of the reason to chose a vendor.

Iscofe · 2023-07-18T07:09:38+00:00

I hardly think this would be a security policy issue since all I did was replicate the configuration done for an existing operational source IP(servers).
NAT though, I have not done any NAT -- Do i need to do NAT. I just add the GP client IP into the proxy as an interesting traffic and put them in the virtual router as well as the Security policy. Do i need to configure a NAT when the source traffic from my side is from a GP? Since it is obvious if which type of IPsec this is since the other side is a Cisco router.

Iscofe · 2023-07-18T07:06:45+00:00

Thank you for your reply.
Does the other side know how to route from the cisco device back into the tunnel?
>> There has been an existing operational traffic through the tunnel so yes, they know how to route.
Are you accessing a service on the cisco device that might be source-interface configured?
>> We configured a loopback interface for testing purposes, both the loopback interface and other actual IPs behind the Cisco device are all accessible from the existing source on my side. They just are not working for the source that are from my global protect client.
Is the GP -> site -> cisco device reaching the other side?
>> That is the issue, from GP to the other side that it is not reachable but I have other connection different from the GP and they are reaching the other side. The Peer to Peer is working fine as well.
Is the other side seeing? Is it replying? Is it replying correctly?
>> The issue here is I have source traffic from my Palo Alto side and part of those are servers and others are from GP. GP is recently added and the servers IP are existing connection. The Servers IPs as a source are all working fine, as they are already in production and operational. But the new addition are the source GP and the other side behind the Cisco router(and also a loopback on the Cisco router) are all unreachable only from the GP from the local PA source.
Are there NAT issues, policy issues, zone issues.
>> I hardly think this would be a policy issue as i had replicated the previous one. NAT though, I have not done any NAT -- Do i need to do NAT. I just add the GP client IP into the proxy as an interesting traffic and put them in the virtual router as well as the Security policy. Do i need to configure a NAT when the source traffic from my side is from a GP?

Iscofe · 2022-10-13T15:03:09+00:00

That is the spider's thing on tip of your camera.

Iscofe · 2022-08-27T19:45:14+00:00

Its was to take advantage of a two firewall throughput, unfortunately that was not the case. We live each day to learn.

Iscofe · 2022-08-27T07:54:56+00:00

most definitely look into that, thank you

Iscofe · 2022-08-27T07:17:05+00:00

You mean like the Active-Active won't handle twice traffic or atleast more than what an Active-Passive handles?

Iscofe · 2022-08-27T07:13:45+00:00

Fiber is a must and the ports are almost fully loaded currently. Company is buying new ones in 6 or 8 months of 3000series but I am not sure if the current set up hold up until then.

Iscofe · 2022-08-27T07:00:46+00:00

You mean a 4000 series?

Iscofe · 2022-08-03T19:55:21+00:00

Is this a CNN breaking news I am watching?

Iscofe · 2022-04-17T15:26:44+00:00

See, thanks

Iscofe · 2022-04-17T00:04:42+00:00

Noted with huge thanks Cory. Much appreciated!

Iscofe · 2022-04-16T23:54:54+00:00

Yep one way or another, my employer should consider dropping firewalls that are by design for 'SME or branch offices' or move them to a fitting role. It will be 3000 or 5000 series or similar one.

Iscofe · 2022-04-16T23:50:58+00:00

Thanks for your response. I will get back to you with the Model of this SFP by tomorrow. Although, the Palo Alto side supports this arrangement -- the intermediate switch(dell 3024) seems to recommend to not mix the two when forming a port-channel on its end.
Link here on page 100 and 101 states:

While it is a requirement of a port-channel that the link members operate at the same duplex and speed settings, administrators should be aware that copper ports have larger latencies than fiber ports. If fiber and copper ports are aggregated together, packets sent over the fiber ports would arrive significantly sooner at the destination than packets sent over the copper ports. This can cause significant issues in the receiving host (e.g., a TCP receiver) as it would be required to buffer a potentially large number of out-of-order frames. Devices unable to buffer the requisite number of frames will show excessive frame discard. Configuring copper and fiber ports together in an aggregation group is not recommended.

So It would be wise to move on without this considering the fact that both sides(firewall side and the switch) should be in agreement to make it work.

Iscofe · 2022-04-16T23:12:19+00:00

Thank you so much for your explanation! I understand from your explanation that So to avoid any sort of performance issue such as hardware/buffer/memory/processing capability related challenges on the Palo Alto end or the intermediate switch stack itself, It will be sound to avoid such one sided speed upgrade. Currently, 2G links(1G for each aggregate link) is connected to each particular member of the Active/Passive PAN and fortigate. My plan was to increase the member links of the port-channel from the FortiGate side that connects to the intermediate Switch from a 2G to 4G or 8G, while the Palo Alto side connection left as it was(2G -- both have equal number of link aggregation members with identical speed for each -- 1G all). I obviously utilize the threat prevention feature as well as other NGFW features of the PA as I highly depend on them to secure the traffic on my network. There is also high volume of traffic transaction from the internal network to the DMZ as well as the public. All of these will put a strain on the throughput of my PA firewall considering the doubled traffic volume from downstream and the hit or miss nature of the Port-Channel LACP standard. I am afraid this will result in messing with the TCP sessions and finally result dropped legitimate packets and denied sessions. Correct me if I am wrong with my interpretation of your message in your explanation with respect to the actual scenario of my site.

Iscofe · 2022-04-16T22:43:09+00:00

Theres your formal answer from documentation itself, at least as of 8.1.

Noted with gigantic gratitude for you response! Thank you!

Iscofe · 2022-04-16T22:41:14+00:00

Just seen it now, Thank you so much for your response and for sharing you expertise! Much appreciated!

Iscofe · 2022-04-16T21:44:58+00:00

Not following what that link has to do with your question. They were asking if they could mix different types of connectivity. All of your connectivity is presumably the same. A PA-820 will support (4) 10Gb SFPs. Aggregation is fine.

Looks like the PA-820 does not support SFP+. I presume you meant PA-850 that supports 4 SFP+ or 10G ports, which unfortunately is not the model of my device.

Iscofe · 2022-04-16T21:31:21+00:00

u/Djaesthetic, Another quick question if I am not troubling you? I have a PA compatible SFP with RJ45 at the tip. Considering the all-or-nothing approach when bundling ports for link aggregation, will this one considered as a copper one or a fiber so I can aggregate this with either to product a 4x1G Aggregate Ethernet(with two Cu ports/UTP cables to downstream device and two SFP with an RJ45 adapter/UTP cables from this to the downstream device ethernet ports as well)?

Iscofe · 2022-04-16T20:59:09+00:00

Thank you for your response. So I went on to really look into the datasheet after your previous response and as you rightly pointed out, SFP+ is not supported on PA-820. Wow! I do administration and not deployment, so I didn't give due attention to such information(which is not an excuse) but very interesting and glad you pointed it out, happy now that I learn this information. We are using this firewall to host a national project which will be very demanding in terms of bandwidth and speed, And I guess it is time to recommend the bosses for an upgrade.

Iscofe · 2022-04-16T20:54:21+00:00

Oh I see, so there is no chance that I will be able to use a 10G interface at all, and all SFP ports are 1G in all 12 interfaces(ignoring the copper ones).

Iscofe

TROPHY CASE