Blog: ittavern.com Feedback is appreciated
Yeah, after more testing, we can say that the second IPStunnel was the issue. Re-worked the route over a single tunnel and the whole 100 Mbps are available again. Users are happy, I am happy. Even tho a little bit frustrating.
Thank you for your input!
Ping - Update 2 @Avian_Carrier@infosec.pub @jharrison@infosec.pub @SgtKetchup@infosec.pub
Ping - Update 3 @Avian_Carrier@infosec.pub @jharrison@infosec.pub @SgtKetchup@infosec.pub
Yeah, notifications are really unreliable here. I’ve got another window for more stress test today. Going to post update later, or tomorrow. Focus on MTU/MSS
The ISPs are slow to answer if there is no active outage. Will take some time anyway.
Packets are dropped in bot directions. I am currently looking through the pcaps and will do another stress test later - got another window. MTU/MSS is the prio today.
Added the Update 2. Still some things to do, but we know a little bit more now. Feedback and questions are still welcome.
Ping - Update 2 Your numbers are are still missing since I havent had time to look into the pcaps yet. I hope I can get it done by the end of the week, but we are a little bit wiser.
Ping - Update 2
Ping - Update 2 @Avian_Carrier@infosec.pub @jharrison@infosec.pub @SgtKetchup@infosec.pub
I hope it is ok to ping you.
Not yet. Just got access to the test clients and I have planned to do a troubleshooting session tomorrow in the morning. Not a big fan of stress testing the network on a working day haha
Will do. I’ll updated the original post most likely and ping you. I’ve added a per-IP traffic shaper to limit the bandwidth, so this one user won’t be able to slow down the location and I am about to prepare the troubleshooting session on the weekend.
Not sure on the logging. I’m a data center guy and would rather see firewalls in the trash lol. They usually just cause problems.
Haha - I’d like to disagree, but you are right.
For the WAN, surely there is some way you can reach those sites over the general internet. You have ISP connections.
I for sure could do it, but it is not that easy to expose a server to the internet. There would be multiple departments involved and I need to get permission. And yeah, even with IP whitelisting. I guess that will be my last resort.
Still waiting for the test clients. Probably going to shift some hours into the weekend so I don’t disturb daily business.
No worries, thank you for your input!
Good points!
I’ll keep that in mind
You are right. Still an active policy that we have to work on.
Could be, for sure. I could disable the security profile for some tests and check if it happens with it turned off. Good points, thank you.
I am certain that we block ICMP on multiple FW in between. I could allow it temporary and check. Good suggestion.
Will compare it as soon as I get my hands on the machine.
And yeah, we do tend to block ICMP over here too.
Getting a pcap of another client could bring some insight, yeah.
SSH is used for the data transfer. Without knowing it at this moment, I’d assume scp or rsync. You mean whether all their internet traffic is routed through the active SSH session?
I haven’t had the chance to get a pcap yet. As soon as I get my fingers on the test clients, I’ll check them and additionally do testing with TCP and UDP transfers. I’ll let you know.
Just to clarify: this would be the limit for a single TCP connection and yes, could be the limit for this one download. This would not explain, why the rest of the location is affected if theoretically 90% of the bandwidth is still available, no? - Please correct me if I am wrong here.
ADVPN (Auto-discovery VPN) seems to be the equivalent. https://docs.fortinet.com/document/fortimanager/7.2.0/single-datacenter-for-enterprise/282533/advpn
I guess it was easier at some point? - Taht was way before my time there. But we are going to replace the MPLS part with simple internet-breakout points on location and the the rest with SDWAN.
Purely from users complaining and other departments getting frustrated about why their stuff was not working (e.g. Citrix). The new FW had to be installed in a short time and ‘everything’ worked fine at first. Problems only occurred after some load was put on the network. We failed - as in network dep - by NOT doing a stress/limit test of the network and finding this problem immediately, and NOT implementing some kind of monitoring that would have notified us of all those lost packets and connections. We caught up, but we should have done it in the first place, because it is necessary.
Do you mean the ISP/MPLS provider? - If so, not really.