Not applicable
Created on 02-24-2011 02:24 PM
Options
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
TCP connections stop working after handshake
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
8 REPLIES 8
Options
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Welcome to the forums.
The first and biggest question.... What firmware version are you currently running on that device?
Bob - self proclaimed posting junkie!
See my Fortigate related scripts at: http://fortigate.camerabob.com
Bob - self proclaimed posting junkie!See my Fortigate related scripts
at: http://fortigate.camerabob.com
Options
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
PCNSE
NSE
StrongSwan
PCNSE
NSE
StrongSwan
Not applicable
Created on 02-25-2011 07:05 AM
Options
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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!
Not applicable
Created on 03-01-2011 02:25 PM
Options
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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
Options
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
ORIGINAL: pileofrogs FGT3KB-4.00-FW-build279-100519V4, MR2, Patch 1 Do you have a policy from Port8 to Port6 that includes SSH?
Bob - self proclaimed posting junkie!
See my Fortigate related scripts at: http://fortigate.camerabob.com
Bob - self proclaimed posting junkie!See my Fortigate related scripts
at: http://fortigate.camerabob.com
Not applicable
Created on 03-02-2011 07:28 AM
Options
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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..
Options
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
PCNSE
NSE
StrongSwan
PCNSE
NSE
StrongSwan
Options
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
also add
diag debug flow show funct enable
Rackmount your Fortinet --> http://www.rackmount.it/fortirack
Rackmount your Fortinet --> http://www.rackmount.it/fortirack