TCP connections stop working after handshake

[#1]

Greetings All. I have a weird problem that I' ve been sleuthing for a few weeks and I was hoping one of you could shed some light. I' m a unix sysadmin and there is a Fortigate between my servers and the rest of the networks. From some locations one cannot use ssh and many other protocols to connect to my servers. I' ve done a great deal of packet sniffing and we can see packets leave the client and enter the Fortigate but not come out, hence my posting on the Fortinet forum. I hope I can describe the problem well enough that one of you will recognise some feature or behaviour and you can tell me what it is. Our Fortigate presently has three ports (ports in this case being the physical jacks on the box) in use. The mgmt1 port and two regular ports (port6 and port8). Port 8 is connected to a switch where all my servers live. Port 6 is connected to our wireless and our library computers (we' re a community college). The mgmt1 port is connected to everything else, including our student labs, our employee computers and the internet. Users in the library and on the wireless systems (port6) cannot use ssh (and many other protocols) though they can use HTTP and FTP with my servers (port8) and they can use those protocols with everything else (mgmt1). The SSH port is not blocked on the Fortigate. There is no traffic shaping enabled and no filtering beyond simple block-don' t-block filters. Here' s where it starts to get weird: The Fortigate configuration appears to allow the traffic that is failing and the failure does not behave like a normal blocked-firewall. The tcp syn-ack handshake completes. The client can send some data, as much as it wants, until the server sends any data. Once the server sends data, the client can no-longer send any data. If the server is the first to send data, the client can not send any data at all. After the client can no longer send any data, the ack packets for data from the server continue to flow to the server. This behaviour is seen with SSH, telnet and netcat on every port I tried except port 21. Why do I think this is happening in the Fortigate? From the networks attached to port6 of the Fortigate, I can connect to ssh servers on other parts of the network and the internet (things connected to the Fortigate via mgmt1) while I cannot do so to servers on the subnet attached to port8. I' ve run tcpdump on the client, the server. I' ve put sniffers directly between Fortigate port6 and the networks it services and I' ve done the same with port6. These show the blocked client packets leave the client, enter the Fortigate and not leave the Fortigate. This is not to say that the Fortigate is broken or even misconfigured. Maybe my servers or my local switch is doing something to trigger this behaviour on the Fortigate? If so I still need to know why the Fortigate is blocking those packets, so the question remains the same. This behaviour looks to me like a firewalling feature meant to restrict clients to FTP (active mode) and HTTP. Port 21 works normally, which allows FTP' s command channel. The other ports only allow a client request followed by a server response, which is all you need in HTTP and (I think) an FTP data channel. This would allow HTTP on non-standard ports, like 8888 or 8080 and block things like IRC while only using data in the TCP layer. Does a Fortigate have a feature that would act like that? To summarise: - Users on one Fortigate port (port6) cannot ssh/telnet/netcat to my servers on another port of the Fortigate (port8) - Users everywhere else (mgmt1) can ssh/telnet/netcat to my servers (port8) - Users can use HTTP and active mode FTP. - SSH is not blocked on the Fortigate - No traffic shaping is enabled - No application level filtering is enabled - It' s not a problem with SSH. I know this because I see the same behaviour with telnet and netcat. The problem is at the TCP level. - The TCP syn-ack handshake succeeds, the client can then send as much data as it wants, after the server sends any data, the client packets are dropped except ACK packets regarding the data sent from the server. Any hints would be greatly appreciated! Dylan Martin Unix Admin Seattle Central Community College

[rwpatterson]

Welcome to the forums. The first and biggest question.... What firmware version are you currently running on that device?

[emnoc]

The firewall policies needs to be reviewed. Can you post this ? Also do you have any asymmetrical routing issues between your client & servers ( port 6 & 8 ) ? If the users on the mgmt port are working 100% correctly ( If I' m understanding your description ) then I would think the firewall firmware is not the issue. How about posting us your route table and fwpolicies for review. i.e get router info routing-table all config firewall policy show That might give us a clearier pictures and explain some of the actions of the firewall.

[#4]

Thanks for responding! I' m not the person who runs the Fortigate, my boss is. He gave me a copy of the config file, but he made me promise to burn and eat it, so I don' t think I can post it here. I' ll ask if I can post parts of it. I' m not sure what the firmware version is, but this string from the config file looks hopeful: FGT3KB-4.00-FW-build279-100519 I' ll ask my boss for permission to post parts of the config and I' ll ask for the firmware version. Thanks!

[#5]

My boss said I couldn' t post the config file itself, but I could paraphrase it. Here is a short-hand of the rules that affect the relevant ports and address ranges. I put them in order but left off the edit numbers. To recap: port6 - my servers port8 - wifi networks mgmt1 - everywhere else including internet and most other networks on campus. The problem is ssh does not work from wifi to my servers (port8 to port6) but it does work from wifi to everywhere else (port8 to mgmt1) and you can ssh to my servers from anywhere other than wifi (mgmt1 to port6). See original post for more details. port6 -> port8 always accept DNS and NTP mgmt1 -> port6 always accpt any port8 -> port6 always accept DNS and NTP port8 -> port6 during school hours, accept HTTP, FTP, SSH and lots more port6 -> mgmt1 always accept any Is it possible that the connections are matching the DNS and NTP only rules and then bailing? That doesn' t make sense because HTTP works... any ideas? Thanks! -Dylan

[rwpatterson]

ORIGINAL: pileofrogs FGT3KB-4.00-FW-build279-100519

V4, MR2, Patch 1 Do you have a policy from Port8 to Port6 that includes SSH?

[#7]

Yes. I was trying to say that with: port8 -> port6 during school hours, accept HTTP, FTP, SSH and lots more but I guess I failed..

[emnoc]

Still sounds like a fwpolicy rule or something along that line. You will need him or you, to debug a flow & report back the outcome. i.e diag debug enable diag debug flow filter daddr " insert your destination here" ( optional ' port 22' ) diag debug flow show console enable diag debug flow trace start 100 Without access to your fwpolicies, we can' t really do to much else.

[FortiRack_Eric]

also add diag debug flow show funct enable