1

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?

  • Check your firewall logs. If Fortigate is dropping packets, it will log that. – Ron Trunk Jun 13 '19 at 13:46
  • @RonTrunk Do you know where this would appear? I've checked all of the potentially relevant log sections and I'm not seeing it. Not sure if it would be in a different section or if it's just not dropping the packets. – Josh Eblin Jun 13 '19 at 14:25
  • I'm not that familiar with Fortigate, but all firewalls log packets if they are denied by policy. – Ron Trunk Jun 13 '19 at 14:56
  • It sounds like the issue is at the clients house, which makes this question off-topic here. You can try asking on Server Fault. – Ron Trunk Jun 13 '19 at 14:58
  • @RonTrunk I had that thought as well, but the client has called his ISP and they say that there is no firewall or anything on the modem. The modem is in full bridge mode. Also, if the issue were with the clients house, wouldn't the packets traverse the Fortigate? – Josh Eblin Jun 13 '19 at 15:01
2

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.

| improve this answer | |
  • As I said in the OP. I've already done a packet capture, on three separate parts of the route. I can see from the CCR router at the corporate office that it is sending the packets, but I am not seeing them in the Fortigate's packet capture. I have checked the Log & Report -> Forward Traffic, and there is nothing there. Our Policy 0 is set to log the violation traffic, so wouldn't it be there if it was denying or dropping the packet? – Josh Eblin Jun 13 '19 at 17:32
  • Do you see the packet captured on the Fortigate's ingress interface? – Zac67 Jun 13 '19 at 17:54
  • I didn't realize it at the time, but the return route actually goes to a different interface on the firewall, so I did not get a packet capture on the ingress interface of the firewall. – Josh Eblin Jun 13 '19 at 18:38
  • I was able to get a packet capture this morning on the ingress interface of the Fortigate, and I can see that the Fortigate receives the SYN, ACK from the far end, then shows an ACK and PSH, ACK from the client end, but does not get a response, but I can see from the corporate router that it is sending a response. – Josh Eblin Jun 14 '19 at 13:00

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.