IPFW IPFW partly blocks outbound connections on allowed port

G

gutaper

Hi all,

I've simple ruleset mostly showed in freebsd wiki. All works, but sometimes ipfw blocks outbound connections on port 80 and 443, which has allowing rule. ipfw not totally blocks outbound connections, but only few ones.

Relevant rules are:
Code: 
outport="$http,$https"
$cmd 00200 allow tcp from any to any $outport out via $ext setup keep-state
$cmd 00299 deny log all from any to any out via $ext

And in /var/log/security I've multiple records like :
Code: 
Dec 17 00:41:12 myhostname kernel: ipfw: 299 Deny TCP 192.168.20.2:63924 149.20.1.201:80 out via re0
Dec 17 00:41:40 myhostname syslogd: last message repeated 4 times
Dec 17 00:42:09 myhostname kernel: ipfw: 299 Deny TCP 192.168.20.2:28472 213.138.116.73:80 out via re0
Dec 17 00:42:09 myhostname kernel: ipfw: 299 Deny TCP 192.168.20.2:63924 149.20.1.201:80 out via re0
Dec 17 00:42:54 myhostname kernel: ipfw: 299 Deny TCP 192.168.20.2:15146 213.138.116.73:80 out via re0
Dec 17 00:43:07 myhostname kernel: ipfw: 299 Deny TCP 192.168.20.2:63924 149.20.1.201:80 out via re0
Dec 17 00:43:13 myhostname kernel: ipfw: 299 Deny TCP 192.168.20.2:28472 213.138.116.73:80 out via re0
Dec 17 00:43:57 myhostname kernel: ipfw: 299 Deny TCP 192.168.20.2:15146 213.138.116.73:80 out via re0
Dec 17 00:44:11 myhostname kernel: ipfw: 299 Deny TCP 192.168.20.2:63924 149.20.1.201:80 out via re0
Dec 17 00:44:17 myhostname kernel: ipfw: 299 Deny TCP 192.168.20.2:28472 213.138.116.73:80 out via re0
Dec 17 00:45:01 myhostname kernel: ipfw: 299 Deny TCP 192.168.20.2:15146 213.138.116.73:80 out via re0
Dec 17 00:45:15 myhostname kernel: ipfw: 299 Deny TCP 192.168.20.2:63924 149.20.1.201:80 out via re0
Dec 17 00:45:21 myhostname kernel: ipfw: 299 Deny TCP 192.168.20.2:28472 213.138.116.73:80 out via re0
Dec 17 00:46:06 myhostname kernel: ipfw: 299 Deny TCP 192.168.20.2:15146 213.138.116.73:80 out via re0
Dec 17 00:46:19 myhostname kernel: ipfw: 299 Deny TCP 192.168.20.2:63924 149.20.1.201:80 out via re0
Dec 17 00:46:25 myhostname kernel: ipfw: 299 Deny TCP 192.168.20.2:28472 213.138.116.73:80 out via re0
Dec 17 00:47:09 myhostname kernel: ipfw: 299 Deny TCP 192.168.20.2:15146 213.138.116.73:80 out via re0
Dec 17 00:47:23 myhostname kernel: ipfw: 299 Deny TCP 192.168.20.2:63924 149.20.1.201:80 out via re0
Dec 17 00:48:27 myhostname syslogd: last message repeated 1 times
Dec 17 03:36:10 myhostname kernel: ipfw: 299 Deny TCP 192.168.20.2:25615 104.20.0.85:443 out via re0
Dec 17 03:36:48 myhostname syslogd: last message repeated 4 times
Dec 17 03:38:47 myhostname syslogd: last message repeated 3 times
Dec 17 03:39:27 myhostname syslogd: last message repeated 1 times
Dec 17 18:16:22 myhostname kernel: ipfw: Accounting cleared.
Dec 20 10:59:59 myhostname kernel: ipfw: 299 Deny TCP 192.168.20.2:52521 46.137.83.240:80 out via re0
Dec 20 11:01:03 myhostname syslogd: last message repeated 1 times
Dec 20 11:02:07 myhostname syslogd: last message repeated 1 times
Dec 20 11:04:15 myhostname syslogd: last message repeated 2 times
 
gutaper said:
Code: 
$cmd 00200 allow tcp from any to any $outport out via $ext setup keep-state
Click to expand...
This rule only allows the initial three-way handshake (SYN; SYN/ACK; ACK) and creates a state. You need another rule that allows the rest of traffic based on that state. Which is done with a rule like this:
Code: 
$cmd 00101 check-state
 
SirDice said:
Which is done with a rule like this:
Code: 
$cmd 00101 check-state
Click to expand...
This is not true for keep-state or limit action directives. As those type of rules will also do a check-state implicitly.
If the OP would've used record-state or set-limit then a check-state is mandatory before those rules.
Per ipfw() man page:
Dynamic rules, which have a limited lifetime, are checked at the first occurrence of a check-state, keep-state or limit rule, and are typically used to open the firewall on-demand to legitimate traffic only.

Can you please show the output of ipfw show please? Do you experience anything not working? Or is your question solely based on that log output?
 
Sigh, I'm going to stick to answering PF questions, I never seem to get IPFW right.
 
Duffyx said:
Can you please show the output of ipfw show please? Do you experience anything not working? Or is your question solely based on that log output?
Click to expand...
Thanks for reply. This host in my local network. It connects to internet only for system update. So no, I don't experience problem (only seeing this in log). But I've separate gateway with similar ruleset (+ NAT rules) and on that gateway I've same type of blocking connections. So I decide to understand ifpw logic in hope to solve my problem with sshfs and ssh (not connects to host from first attempt, long responses while browsing mounted share etc.)
Code: 
00010      37       1840 allow ip from any to any via lo0
00101       0          0 check-state :default
00110       0          0 allow tcp from any to 1.1.1.1 53 out via re0 setup keep-state :default
00111     206      20991 allow udp from any to 1.1.1.1 53 out via re0 keep-state :default
00112       0          0 allow tcp from any to 1.0.0.1 53 out via re0 setup keep-state :default
00113       0          0 allow udp from any to 1.0.0.1 53 out via re0 keep-state :default
00200  122660  101184971 allow tcp from any to any 80,443 out via re0 setup keep-state :default
00250       0          0 allow icmp from any to any out via re0 keep-state :default
00299       5       1279 deny log ip from any to any out via re0
00301       0          0 deny ip from 172.16.0.0/12 to any in via re0
00302       0          0 deny ip from 10.0.0.0/8 to any in via re0
00303       0          0 deny ip from 127.0.0.0/8 to any in via re0
00304       0          0 deny ip from 0.0.0.0/8 to any in via re0
00305       0          0 deny ip from 169.254.0.0/16 to any in via re0
00306       0          0 deny ip from 192.0.2.0/24 to any in via re0
00307       0          0 deny ip from 204.152.64.0/23 to any in via re0
00308       0          0 deny ip from 224.0.0.0/3 to any in via re0
00310       0          0 deny icmp from any to any in via re0
00315       0          0 deny tcp from any to any 113 in via re0
00320       0          0 deny tcp from any to any 137 in via re0
00321       0          0 deny tcp from any to any 138 in via re0
00322       0          0 deny tcp from any to any 139 in via re0
00323       0          0 deny tcp from any to any 81 in via re0
00330       0          0 deny ip from any to any frag in via re0
00332       0          0 deny tcp from any to any established in via re0
00410 8125253 7855810321 allow tcp from any to me mysshport in via re0 setup limit src-addr 4 :default
00499       0          0 deny log ip from any to any in via re0
00999       0          0 deny log ip from any to any
65535       0          0 deny ip from any to any
 
I think I know what you might be seeing. Try adding this at rule 201 (without setup keyword):
Code: 
allow tcp from any to any 80,443 out via re0 keep-state

Give ipfw show output after half an hour and see if you log file is better.

If that helped I can give you more explanation. But I can also tell you that the above rule is not necessary to get a functioning firewall and only helps to give an explanation to the denied packets you are seeing. Also, given that you do not see/observe any problem, I think there is no problem caused by the denied packets.

gutaper said:
So I decide to understand ifpw logic in hope to solve my problem with sshfs and ssh (not connects to host from first attempt, long responses while browsing mounted share etc.)
Click to expand...

Please don't do that, you are giving us XY problems to deal with, which are not that efficient to solve.
 
Last edited:
Duffyx said:
above rule is not necessary to get a functioning firewall and only helps me to give an explanation to the denied packets you are seeing
Click to expand...
RTFM about ipfw "setup" option, and tcp three-way handshake - I think I clear it for myself already.
Duffyx said:
Please don't do that, you are giving us XY problems to deal with, which are not that efficient to solve.
Click to expand...
Us? Feel free to ignore my questions if I disturbing you :) But thanks for your reply anyway - it gives me digging direction.
Duffyx said:
I think there is no problem
Click to expand...
I prefer to understand what I'm doing, rather than ctrl-c ctrl-v from examples :)
 
You must log in or register to reply here.
Back
Top