I have a user that is trying to access his company network resources on his home network. He is able to access SMB shares and other resources, but he is unable to access their AS400 on any computer in his network, and unable to update his Exchange email on his iOS email app on any iOS device on his home WiFi. He can access his email through the Outlook app. There is another user at his company that has the exact same set up, and does not have these issues.
The set up is as follows:
Mikrotik Hex (at client's house) -> Mikrotik CHR (used as Tunnel Router, hosted on my company's VM server) -> Fortigate Firewall (hosted in my company's server rack) -> Mikrotik CCR (at client's corporate office)
Each device above is connected via IP tunnel using BGP, except the Fortigate. It shares Vlans with the CHR and the CCR and uses BGP.
The user can ping both devices from home without problem.
I have done packet captures on the Hex, the Fortigate, and the CCR.
I see the Hex is getting most of the traffic necessary. For the AS400, it goes through port 449 at first, and that TCP connection finishes, then through port 8476, and that TCP connection never finishes. My research tells me that port 449 is a server mapper for the IBM device that hosts the AS400, and port 8476 is a signon verification service. At first, I thought that since he was not getting all of the TCP responses necessary from port 8476, there was a verification problem, but I think that he would get something that would confirm this. For the Exchange email on his mail app, I can see the iPhone reaching out over port 443, and confirmed that it should use HTTPS, but he's not getting the last part of the TLS handshake. He sends the Client Hello, gets the Server Hello, sends the Client Handshake and Encrypted message, but never receives the Server Handshake/Server Done message back. On both tests, there are a lot of TCP Retransmissions, TCP Dup Acks, and TCP Out of Orders.
My next packet capture was done on the Fortigate and CCR. From the Fortigate, the first thing I notice is that there are almost zero TCP Retransmissions, TCP Dup Acks, and TCP Out of Orders. I see the same packets being sent back and forth as far as TCP connection packets, but it's almost like the Fortigate is dropping the extras.
The last packet capture on the Mikrotik CCR at the corporate office shows that all of the missing packets from the Hex are being sent, and the TCP Retransmissions, TCP Dup Acks, and TCP Out of Orders are there as well. At first, my thought was there there's a firewall rule blocking this traffic. So, I looked through all the firewall rules, including ones that are outside the domain of this connection, and there is nothing that would drop this traffic. Then I thought, even if there was a firewall rule that drops this traffic, it should also drop the traffic to the other user who doesn't have these problems.
Does anyone have any ideas as to why this traffic is not getting back to or being dropped by the firewall?
Best Answer
On the Fortigate GUI, go to Log & Report -> Forward Traffic. You might need to filter by Source or Destination (IP address). Likely, no firewall rule matches the packet and it was dropped (Policy 0, Implicit Deny, Result "Deny: policy violation").
Alternatively, use IPv4 Policy -> Policy lookup and specify source, destination, ports, protocol and check which policy applies.
If the packet in question does not show up in the log and the policies are good you can use Network -> Packet Capture for a packet-level analysis. If that doesn't show anything either, the far end isn't sending the packet and you need to check there.