- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Abnormal traffic behaviour to AWS
Hi All
I have a bit of a weird one, hoping someone might have an idea :)
One of my customers has a pair of 500E's in Active/Standby running 7.0.12. All interfaces, routes, policies, firmware etc are exactly the same.
We have a rule to allow selected internal subnets out to several AWS subnets via the internet, no VPN in use. Recently we have found that if FW01 is Active the customer experiences problems with connectivity to their phone system based in AWS, if we make FW02 active the problem goes away. The rule is only allowing HTTPS and UDP 3478 and no security profiles are active.
The 3 AWS IP's we identified as being used 2 work on FW01 1 doesn't and on FW02 all 3 work.
We have engaged TAC but no root cause has been found yet and we need to run more diagnostics with them. However until the customer agrees that we can fail back to FW01 (causing issues for them) i was wondering if anyone might have seen something similar.
Thank You
Mark
- Labels:
-
FortiGate
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hello Mark,
Generally it is hard to find a root case without live debug traces (i.e. traffic dump).
You may consider to check forward traffic logs. Moreover, (rather unlikely to be the root cause of the issue though) you may check whether related sessions are synchronized between HA units.
Also could you please clarify whether FW01/FW02 use the same ISP.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hi
I will look at the session sync as i'm running out of idea's currently lol.
Yes they are using the same ISP, we have lots of other traffic going through the same interfaces and they are not affected it is purely this one traffic flow which is the problem. Because of that it makes me wonder if it's the AWS end but they have already looked and said "not our issue"
Regards
Mark
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hello Mark,
You may consider to check forward traffic logs. It can give you a hint at which stage connection failed.
In order to narrow down the issue you may consider to run "diagnose sniffer packet any 'host <destination IP address>' 6 0 a" while the issue is triggered.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hiya
Have checked the session sync and it is enabled on both devices. I will need to run the packet capture on FW01 when the customer allows us to fail back to that device. I did review a packet capture from when the issue occurred back in May but there was nothing conclusive.
Regards
Mark
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hello,
You may consider to enable session-pickup-connectionless and session-pickup-expectation (SIP/RTP traffic) in case it is not enabled.
config system ha
session-pickup-connectionless Enable/disable UDP and ICMP session sync.
session-pickup-expectation Enable/disable session helper expectation session sync for FGSP.
end
In the existing packet capture you may consider to check whether SIP signaling is forwarded in both directions and whether SIP pinholes are opened (if applicable).
