opening ports is causing problems

N

nonsequitur

I just moved from openSUSE and it was quite the adjustment and these forums have been truly superb is getting me moved in the right direction - thank you! One problem remains. This home server has two NICs, bce0 (public IP) and bce1 (private IP). It's also my DNS and DHCP server for the internal network, actually, it's also running PostFix and Dovecot and SSHD until I get another box. All of these are working great with ipfw+nat.

What's not working is my kid's Minecraft server running on port 25565 (rule 00550 below). I can see the server from other networks but when I connect the game is unstable and I get odd disconnects. Once a connection is established though and I stop the firewall, the connections are maintained and the game is perfectly playable. I've no idea what's happening. This is the [CMD=]ipfw show[/CMD] output.

Code: 
00080 allow ip from any to any via lo0
00081 deny ip from any to 127.0.0.0/8
00082 deny log ip from 127.0.0.0/8 to any
00500 allow tcp from any to any dst-port 80 in via bce0
00510 allow udp from any to any dst-port 53 in via bce0
00515 allow tcp from any to any dst-port 53 in via bce0
00520 allow tcp from any to any dst-port 2222 in via bce0
00530 allow tcp from any to any dst-port 25 in via bce0
00540 allow tcp from any to any dst-port 993 in via bce0
00550 allow tcp from any to any dst-port 25565 in via bce0
00800 divert 8668 ip from any to any via bce0
01100 check-state
01101 allow ip from any to any via bce1 keep-state
01102 allow ip from any to any out via bce0 keep-state
01103 deny tcp from any to any established in via bce0
01104 deny log ip from any to any frag in via bce0
01200 allow icmp from any to any icmptypes 3
01201 allow icmp from any to any icmptypes 4
01202 allow icmp from any to any icmptypes 8 out
01203 allow icmp from any to any icmptypes 0 in
01204 allow icmp from any to any icmptypes 11 in
60000 deny log tcp from any to any in tcpflags ack,rst recv bce0
65000 deny log ip from any to any
65535 allow ip from any to any

When I enable LOGging on that port, I see all kinds of weirdness that I just don't understand and I was hoping that one of you IPFW gurus might know. Here's a snippet of the /var/log/security when logging is on.
Code: 
Mar 31 00:41:47 gandalf kernel: ipfw: 550 Accept TCP 172.17.3.203:50673 178.18.16.194:25565 out via bce0
Mar 31 00:41:48 gandalf kernel: ipfw: 550 Accept TCP 172.17.3.203:50670 109.74.240.179:25565 out via bce0
Mar 31 00:41:48 gandalf kernel: ipfw: limit 5 reached on entry 550

If I don't limit the logging, I can get 1000's of entries.

Is there something wrong in my firewall configuration? Thanks in advance for any insight!
 
After a week wrestling with IPFW I gave in and switched to PF. Everything is working fantastically well now. I guess I need to read the FreeBSD IPFW guide more thoroughly before diving in and just hacking on it the next time ;-)
 
You will find that a majority of people use PF nowadays. The only thing setting IPFW apart (in my opinion) is the pipe feature. Other than that, PF will do absolutely dandy for stateful firewalling and anything you throw at it.
 
That was my experience with ipfw(8) as well. I'm well versed in rule based matching and the flow of data in packet filtering but somehow IPFW feels like a crude hack compared to pf(4).
 
IMHO, most of the reported ipfw issues boil down to bad and heavily outdated documentation in the Handbook and questionable choices for pre-installed rulesets.

For example. In the Handbook Chapter 31.6 - IPFW. In-kernel-NAT is mentioned exactly one time in the first line of that chapter, and then never again. As a matter of fact, all the examples and installation hints are using the for several years outdated divert to natd method.

The pre-installed rulesets are also utilizing natd and not in-kernel-NAT, and even worse, as far as I can tell, there is no example for a working statefull ruleset.

The biggest obstacle, however, when using NAT (either divert/natd or in-kernel-NAT) together with stateful rulsets is the fine detail, that all stateful rules must be enveloped by two NAT rules, one for incoming packets and one for outgoing. This information is present in said handbook chapter, you only need to find it in the course of reading a very long blurb of outdated and unrelated information.

That said, the outline of a working ipfw/NAT stateful ruleset may also be quite simple, the only problem is that the Handbook tells a complicated, outdated and questionable if not wrong story. IMHO, it would be better to remove this chapter altogether, and once somebody is already there, delete the even more mis-leading Handbook Chapter 15.9 - VPN over IPsec. People spent hours in RTFM, to no other avail than finally finding out that This Manual is Really Fucking TMRF.

A quite simple stateful ipfw/NAT ruleset for a two NIC gateway including port redirection to a VPN server could look like the following. Pay special attention to the two NAT rules 100 and 10000, and how these envelope all the stateful ipfw rules. Replace WAN and LAN by the actual interface names, and 192.168.0.1 by the actual local IP of the VPN server.

Code: 
#!/bin/sh
ipfw -q flush
ipfw -q nat 1 config if WAN reset\
                            redirect_port tcp 192.168.0.1:1723 1723\
                            redirect_port udp 192.168.0.1:500   500\
                            redirect_port udp 192.168.0.1:4500 4500

# Allow everything within the LAN
ipfw -q add 10 allow ip from any to any via LAN
ipfw -q add 20 allow ip from any to any via lo0
ipfw -q add 30 allow ip from any to any via ng*

# Catch spoofing from outside
ipfw -q add 90 deny ip from any to any not antispoof in

ipfw -q add 100 nat 1 ip from any to any via WAN in
ipfw -q add 101 check-state

# Rules for allowing dial-in calls to the PPTP and L2TP/IPsec VPN servers
# that are listening on a LAN interface behind the NAT
ipfw -q add 200 skipto 10000 tcp from any to any 1723 via WAN in setup keep-state
ipfw -q add 201 skipto 10000 udp from any to any  500 via WAN in keep-state
ipfw -q add 202 skipto 10000 udp from any to any 4500 via WAN in keep-state

# Rules for outgoing traffic - allow everything (1000) that is not explicitly denied)
ipfw -q add 1000 deny ip from not me to any 25 via WAN out

# Allow all other outgoing connections
ipfw -q add 2000 skipto 10000 tcp from any to any via WAN out setup keep-state
ipfw -q add 2010 skipto 10000 udp from any to any via WAN out keep-state

# Rules for incomming traffic - deny everything (9998/9999) that is not explicitly allowed
ipfw -q add 5000 allow tcp from any to me 22,80,443,3690 via WAN in setup limit src-addr 20

# Catch tcp/udp packets, but don't touch gre, esp, icmp traffic
ipfw -q add 9998 deny tcp from any to any via WAN
ipfw -q add 9999 deny udp from any to any via WAN

ipfw -q add 10000 nat 1 ip from any to any via WAN out

# If the Kernel has been build using the option IPFIREWALL_DEFAULT_TO_ACCEPT
# then the rule 65534 is not needed and it may be commented out
ipfw -q add 65534 allow ip from any to any
 
What irritatated me the most was the need to have skipto rules to have working outbound NAT. Kind of reminded me of the days when GOTO was a popular programming technique because of popularity of BASIC programming language.
 
Great background information folks - I'm so glad it wasn't just me :)

Suffice it to say, I'm loving FreeBSD 9.1, it's exactly the breath of fresh air my servers needed!
 
You must log in or register to reply here.
Back
Top