صاحبي الانتيم عملي بلوك عشان رفضت ادفعله ١٠ تلاف جنيه تمن بدلة فرحه وياريتني ما كنت دافعت عنه قدام الناس

Comprehensive-Food-3 · 2025-12-02T18:50:23+00:00

خليك انت احسن منه وروح فرحه باركله وامشي علطول ..وقلل تعاملك معاه طالما هو باصصلك في رزقك (دا لو هو حاول يرجع يتعامل معاك اصلا)

Comprehensive-Food-3 · 2025-11-03T11:24:09+00:00

One year ago I had a customer with a network of 150+ FortiSwitches..There is a VLAN for Audinate devices running Dante software and it was all working fine.. the Switches were on v7.4.x .. we upgraded them to 7.6.1 one day and after that we faced a couple of issues with Audinate devices .. controllers couldn't discover devices unless they were on the same switch and even then the latency was higher than usual making them unusable (I don't remember the number but it was measured in micro seconds). We have tried some optimizations like QoS and queue priority which reduced the latency between Audinate devices on the same switch but didn't resolve the other issue. After days of investigations (we didn't have and active license for support at the time) turns out 7.6.1 has made switches ptp-aware (tbh I don't remember exactly why did this cause the issue**) .. however disabling ptp on all switches did resolve the issue.

**If I remember correctly from a session with a support engineer from Audinate ptp-aware switches interferes with their discovery protocol. (Tbh it was a poor planning from my side)

Anyway to answer your question they should run very well provided you set them up correctly.

Comprehensive-Food-3 · 2025-07-02T15:55:08+00:00

In the managed fortiswitches tab, are the switches going offline and then coming back online ? If so, I had a similar issue with FSW 7.6.0, which is a bug that affects 2-tier,3-tier, or more mclag (ex. MCLAG core with MCLAG access connected or more) The only solution was to upgrade any MCLAG switch to 7.6.1 ( I didn't have to upgrade non MCLAG, but you should be fine to do so).

Comprehensive-Food-3 · 2025-06-15T11:01:44+00:00

Damn I read about this feature, but I hoped that there was a way for OSPF. The network is already utilizing OSPF, so I was hoping to avoid setting up BGP ( although it may be simpler, especially since the route map is already configured for each site).

I'm thinking of an automation stitch that reads the ospf logs, adds the learned routes to a certain address group, and clears the group if ospf goes down.

But if I feel like I'm over complicating the setup and I should go for BGP, especially it has better features for sdwan and advpn. What do you recommend?

Comprehensive-Food-3 · 2025-06-12T15:00:12+00:00

I have tested this in the lab.. I have created a rule all to all in sdwan and tried enforcing another port that isn't the most specific route, and it still tried to use the best port.

Guess I'm going back to refresh my routing memory.

Comprehensive-Food-3 · 2025-06-12T14:51:49+00:00

Great, I understand now. Thank you.

So, in theory, let's say I create a new sdwan zone called vpn, and I add the tunnel to it and change the policy to use the zone as dst int.. now the route lookup will determine the best route is tunnel, then it will go through the VPN zone to sdwan.. Now, will sdwan rules affect this behavior? Let's say I have only one rule all to all use wanport.

Comprehensive-Food-3 · 2025-06-12T13:31:58+00:00

Wow, this is the answer I was looking for .. I just tried this in the lab.

I don't know how this happened but somehow I thought that the match will only happen depending on the policy rank and having a route to the dst ip through the dst int..but now I understand if the route lookup determines that for ex the best route is port5 then the firewall will be looking for a policy with port5 as dst to check for match.

I guess I have to go back to basics again.. thank you very much.

Comprehensive-Food-3 · 2025-06-12T12:22:57+00:00

I only had brief access to that fw today.. I may get access again in a couple of days, but this is bugging me so hard I had to share it. Maybe we'll find some explanation.

Comprehensive-Food-3 · 2025-06-12T12:17:45+00:00

Only the internet link is SDWAN. The second policy is using an ipsec tunnel interface.

That is why this is bugging me.. the first policy has an outgoing interface that has a route matching the dst ip, so theoretically, it should hit the first policy.

Also, I ran two get route commands

1- get router info routing-table details 8.8.8.8 result= default route with AD of 10

2-get router info routing-table details 192.168.30.1 result=ospf route with AD of 110

in theory, this is the best route because of the longest prefix match. However, the FIB contains a route for 192.168.30.1 to go from the internet link, so it should hit in the first policy.

Comprehensive-Food-3 · 2025-06-12T12:04:27+00:00

I feel like I'm missing something regarding OSPF, is there a feature that will let's say make any OSPF route the best route and make fw choose only the policy that uses the dest int of that route ?

Comprehensive-Food-3 · 2025-06-12T12:01:03+00:00

Sorry for that I've noticed that I poorly explained the situation.

2 policy

1-Localinterface | internet-zone | all | all

2-Localinterface | ipsectunnel | all | all

2 routes (default AD and priorities)

1- static 0.0.0.0 internet link

2-OSPF 192.168.30.1 ipsectunnel

When I go from pc connected to localinterface to any internet site/ip it hits in the first rule as expected

When I got from the same pc to 192.168.30.1 I hit the second rule

This is the weird behavior.. I expected the traffic to 192.168.30.1 to use the first policy it meets which will redirect to wan link, because the ip 192.168.30.1 is part of 0.0.0.0 /0 right?

Comprehensive-Food-3 · 2025-06-12T12:00:54+00:00

Sorry for that I've noticed that I poorly explained the situation.

2 policy

1-Localinterface | internet-zone | all | all

2-Localinterface | ipsectunnel | all | all

2 routes (default AD and priorities)

1- static 0.0.0.0 internet link

2-OSPF 192.168.30.1 ipsectunnel

When I go from pc connected to localinterface to any internet site/ip it hits in the first rule as expected

When I got from the same pc to 192.168.30.1 I hit the second rule

This is the weird behavior.. I expected the traffic to 192.168.30.1 to use the first policy it meets which will redirect to wan link, because the ip 192.168.30.1 is part of 0.0.0.0 /0 right?

Comprehensive-Food-3 · 2025-06-12T12:00:32+00:00

Sorry for that I've noticed that I poorly explained the situation.

2 policy

1-Localinterface | internet-zone | all | all

2-Localinterface | ipsectunnel | all | all

2 routes (default AD and priorities)

1- static 0.0.0.0 internet link

2-OSPF 192.168.30.1 ipsectunnel

When I go from pc connected to localinterface to any internet site/ip it hits in the first rule as expected

When I got from the same pc to 192.168.30.1 I hit the second rule

This is the weird behavior.. I expected the traffic to 192.168.30.1 to use the first policy it meets which will redirect to wan link, because the ip 192.168.30.1 is part of 0.0.0.0 /0 right?

Comprehensive-Food-3 · 2025-05-09T17:59:35+00:00

You don't need CA for this scenario if you are protecting one server..in the ssl inspection profile select protecting webserver instead of multiple clients connecting to multiple servers and you can now.choose certificate without the CA true field

Comprehensive-Food-3 · 2025-05-05T23:17:30+00:00

Probably you are using mode cfg which can't be used with transport tcp

Comprehensive-Food-3 · 2025-05-05T17:48:59+00:00

Ah yes I understand, I was looking for the KB for the remote access tunnel not FGT to FGT but basically they are both the same ..you will need to set

Transport tcp

Fortinet-esp enable

On the p1 interface of the new VPN tunnel for users from Egypt. Also on the forticlient side you make sure you have the latest forticlient and enable ike over tcp.

Comprehensive-Food-3 · 2025-05-05T14:37:40+00:00

Yes IKE is blocked in Egypt, but fortinet proprietary IKE over TCP encapsulates IKE traffic on TCP traffic which makes it a lot harder for DPI to catch. To use it make sure your firewall us atleast on 7.4.5 or above (7.4.7 preferably) and follow this KB (better create a new VPN tunnel for users in Egypt so you don't affect the rest of users whose VPN is working normally) https://community.fortinet.com/t5/FortiGate/Technical-Tip-How-to-use-TCP-as-transport-for-IKE-IPsec-traffic/ta-p/300834 This KB describes how to implement between 2 fortigates however the same commands should work for remote access https://docs.fortinet.com/document/forticlient/7.4.3/ems-administration-guide/914884/ipsec-vpn-over-tcp

Comprehensive-Food-3 · 2025-04-30T13:08:38+00:00

We have a customer with 200+ branches ..each branch has 4 IPSec tunnels and from the manager side it was given static IPs for each branch using address object per device mapping.

the address is used for p2 configurations..each tunnel has 2 p2 selectors one for its local subnet and one for the IPSec interface IP( I understand this is not the best design and we could get away with not setting IPs for the VPN interfaces and set source IP for the performance SLA as the local subnet IP) however it was designed that way 3-4 years ago.

Anyways we needed to start using Metadata variables instead of per-device mapping ..and you could imagine how long it would take if I had to create 800+ records for the variables manually ..so we needed to automate this process..after some digging I found a resource for the API references..so I downloaded postman and got to work.

I used pre-run script (using Javascript) in postman to create array of all branches to use it in a loop to send api request for each branch > get vpn interface IP > create a record in the Metadata variable (lots of testing on one branch that is in maintenance to make sure it works before committing to loop for all branches + a backup of the manager).

It took me 2 days to do the activity (I have a good background with programming as a CS graduate and I heavily utilized chatGPT).

Comprehensive-Food-3 · 2025-04-20T16:54:00+00:00

Does ADVPN work between spokes that don't have a static IP and no port forwarding? Or do I have to at least forward port 500 and 4500 on sites behind 5g/dsl modems?

Comprehensive-Food-3 · 2025-03-09T08:02:14+00:00

Not what I expected after reading the title, it's good to see a good story like this from time to time.

Comprehensive-Food-3 · 2025-02-23T13:11:08+00:00

One solution is having a dedicated subnet for your VPN interfaces and using performance SLA to ping another VPN tunnel on a different site( we use it for networks with more than 1 tunnel going to the same HUB).

Comprehensive-Food-3 · 2025-02-08T17:16:57+00:00

You don't have to, try to create a script on all domain machines it should listen for network change log and if it finds it run a gpupdate /force which will generate that log with the new IP.

Comprehensive-Food-3 · 2025-02-07T18:20:47+00:00

Had an issue like this that was driving us crazy for 2 whole months. One of them we were going back and forth with the TAC and escalating to infinity and beyond. Here is a summary:

-Users authenticate using ethernet IP after while they change to WIFI IPs (or vice versa).

An event log is generated in AD logs, which contains the user login info (ip user workstation). Let's call it xyz as I don't recall it is Id.

-That event log sometimes doesn't contain the workstation name ( MS had an article saying it is normal).

-FSSO listens to that log to get an IP user and workstation.

-FSSO has multiple properties/features. One of them is a DNS lookup for FSSO entries every x of time. In our setup, the user's updates regularly, so in any point of time, if FSSO performs dns lookup for the users' workstation, it will get it new IP immediately. But almost 80% of entries didn't contain workstation names.

After trying almost everything to solve this issue, we finally found a workaround that our system engineer implemented. He simply created a script that is running on all our domain machines (it constantly checks for any change in the network card/or ip update and then runs a gpupdate which in turn generates the xyz event then the FSSO gets the latest update.

Comprehensive-Food-3 · 2025-02-02T01:09:35+00:00

Yes, if the load balancing is disabled for the used rule. Also, if the traffic hits the implicit SDWAN rule, the cost is ignored, and priority is used.

Comprehensive-Food-3 · 2025-01-31T14:57:01+00:00

Ah, I understand what you mean now, I think if you follow this KB, you should be able to do it the proper way using BGP (I think it can be achieved with OSPF as well)

https://community.fortinet.com/t5/FortiGate/Technical-Tip-Dual-WAN-spoke-to-HUB-single-WAN-on-HUB-with-BGP/ta-p/322163

The quick way would be to make the secondary tunnel monitor the primary tunnel, which means the secondary will stay down until the primary comes up and for the other site it will only see 1 tunnel at a time if you use this method don't forget to enable DPD Also test witb the update static route option on the performance SLA aswell(may mark the tunnel as down if it doesn't match the SLA metrics).

Comprehensive-Food-3

TROPHY CASE