# Deny SSH connection, but can still connect ?



## malexe (Dec 3, 2009)

I have this rule 

```
10200 allow tcp from any to any dst-port 22 in via bge0 setup keep-state
```

and I can connect via ssh to the server.

So why do I have such thing in my log:

```
Dec  3 19:19:56 hostname kernel: ipfw: 50000 Deny TCP source_ip:63209 my_server_ip:22 in via bge0
```

I use FreeBSD 8.0 with IPFW.


----------



## graudeejs (Dec 3, 2009)

perhaps you have deny quick few lines higher...

Or deny .... few lines lower... for this statement


----------



## malexe (Dec 3, 2009)

here is my complete list of ipfw rules:


```
00300 allow ip from any to any via lo0
00301 allow ip from any to any via tap0
00500 check-state
01000 allow ip from any to any out via bge0 keep-state
10050 allow tcp from any to any dst-port 80 in via bge0 setup keep-state
10080 allow tcp from any to any dst-port 888 in via bge0 setup keep-state
10100 allow tcp from any to any dst-port 9418 in via bge0 setup keep-state
10199 allow tcp from any to any dst-port 22 in setup keep-state
10200 allow tcp from any to any dst-port 22 in via bge0 setup keep-state
10300 allow udp from any to any dst-port 1194 in via bge0 keep-state
50000 deny log ip from any to any in via bge0
51000 deny log ip from any to any
65535 deny ip from any to any
```

even If have I have a deny rule after, the packet should be allowed from a rule before it. (And it is allowed, because I can SSH successfully)


----------



## graudeejs (Dec 3, 2009)

UPS... I mistaken  it for pf... sorry.... I'm not familiar with ipfw


----------



## idle (Dec 4, 2009)

There is always some packets that will not match any rule, and reach the last one.
Even if you have only two:

```
allow ip from any to any
deny ip from any to any
```
I don't know why, perhaps some buffer overflow.
It's a rarity, no reason to worry


----------



## malexe (Dec 4, 2009)

Really ?! This is the first time I see such behavior. :\


----------



## idle (Dec 4, 2009)

Check your counter for rule 65535.
This is mine from one server:

```
60000 112350152 76310585995 allow ip from any to any
....
65535       249       16583 deny ip from any to any
```


----------



## DutchDaemon (Dec 4, 2009)

I could imagine that IPFW, even in its 'openest' configuration, would still not accept certain out-of-state packets, weird tcp flags combinations, or orphaned/malformed fragments.


----------



## anomie (Dec 4, 2009)

@malexe: What ssh client are you using? 

It's likely that if you were also logging allowed ssh packets, you'd first see logged accepted packets, followed by one or two logged denied packets. 

See DutchDaemon's post above -- your client may just be sending some strange or otherwise unexpected packets during an ssh session.


----------



## hedwards (Dec 6, 2009)

I'm not really an expert, but do you really want to have both of these written like that? Looking at the handbook, it appears that setup starts the session, and then you require that the packets come through a specific interface. EDIT: What I mean is that there might be a conflict between these two. I'd consider dropping one temporarily and seeing if that fixes things.

I'm not that familiar with IPFW, but I'd assume that you're starting a session and that the 10200 rule is not matching 10199 because it's not recording the state information as being via the bge0. Which should be the case since you don't want an authenticated session moving between interfaces under normal conditions.

```
10199 allow tcp from any to any dst-port 22 in setup keep-state
10200 allow tcp from any to any dst-port 22 in via bge0 setup keep-state
```


----------



## malexe (Dec 8, 2009)

anomie said:
			
		

> @malexe: What ssh client are you using?
> 
> It's likely that if you were also logging allowed ssh packets, you'd first see logged accepted packets, followed by one or two logged denied packets.
> 
> See DutchDaemon's post above -- your client may just be sending some strange or otherwise unexpected packets during an ssh session.



I am using Putty. Anyone had issue with putty on windows ?


----------



## malexe (Dec 8, 2009)

hedwards said:
			
		

> I'm not really an expert, but do you really want to have both of these written like that? Looking at the handbook, it appears that setup starts the session, and then you require that the packets come through a specific interface. EDIT: What I mean is that there might be a conflict between these two. I'd consider dropping one temporarily and seeing if that fixes things.
> 
> I'm not that familiar with IPFW, but I'd assume that you're starting a session and that the 10200 rule is not matching 10199 because it's not recording the state information as being via the bge0. Which should be the case since you don't want an authenticated session moving between interfaces under normal conditions.
> 
> ...



Thanks for noticing that, I will remove one. But I doubt it really has any bad effect.


----------



## hedwards (Dec 11, 2009)

malexe said:
			
		

> Thanks for noticing that, I will remove one. But I doubt it really has any bad effect.


I wouldn't expect it to be causing the problem, but then again I'm not fully familiar with how exactly the states are saved.

And from further review of the error message, it looks like you may have gotten the set up wrong.


```
50000 deny log ip from any to any in via bge0
```
^^ Matches.

```
10200 allow tcp from any to any dst-port 22 in via bge0 setup keep-state
```
^^ Doesn't match currently. I'd try removing 50000 for the time being and see if that fixes things. I forget if IPFW is a last rule wins system or not.


----------



## malexe (Dec 13, 2009)

it is a first rule wins.


----------



## Lowell (Dec 15, 2009)

Have you _ever_ noticed a legitimate ssh connection fail?  If you can't connect the message to the packet that produced it, there's no way to be sure that you have a real problem.  

For example, somebody outside may be trying to sneak a packet through your firewall by sending a TCP packet to port 22 without a SYN but without having an established session.  In that case, your firewall is correctly blocking the attack.

It's also possible that the firewall is losing track of the state somehow, but in that case you would notice your established ssh session dropping.


----------



## malexe (Dec 17, 2009)

Ok thanks for the information ! I will investigate keeping that in mind.


----------

