IPFILTER Troubleshooting

[LordInateur]

Hello,

I am convinced that IPFilter is not blocking anything like it should be. I'm going to get straight to the point because I've done several hours of research, several tutorials, dug through the handbook, looked at all sorts of stuff, and still can't solve it.

Here's what I have:

/etc/rc.conf

hostname="uco_tke"
ifconfig_xl0="DHCP"
ifconfig_xl0_ipv6="inet6 accept_rtadv"
ftpd_enable="YES"
sshd_enable="YES"
# Set dumpdev to "AUTO" to enable crash dumps, "NO" to disable
dumpdev="NO"
apache24_enable="YES"
mysql_enable="YES"
ipfilter_enable="YES"
ipfilter_rules="/etc/ipf.rules"
ipmon_enable="YES"
ipmon_flags="-Ds"

I've also attempted to integrate IPFilter into the kernel. The custom kernel is called UCO_TKE. Also, when I tried to preview this post, the forums complained that I had too much text, so I've only supplied what I added to the file. If I need to upload the entire file, let me know.
/usr/src/sys/i386/conf/UCO_TKE

# Enable IPFILTER
options IPFILTER
options IPFILTER_LOG
options IPFILTER_DEFAULT_BLOCK

Here are my options for IPFilter:
/etc/ipf.rules

block in quick on any from 172.18.9.218 to any
pass in all
pass out all

Notes:

• I am using FreeBSD 9.1-RELEASE, which hasn't passed it's EOL.
• The IP address "172.18.9.218" is a local IP address that I was using to test the firewall. The FreeBSD machine runs an Apache server, and I was still able to access the "website" on the machine. Also, the machine responded to pinging, even after the ruleset file was reloaded.

I've given all the information I can think of right now, I'm quite tired so I might have missed something. If I need to supply any information, let me know. Thank you!

 

[SirDice]

I would suggest not using IPFilter. The code is rather old and hasn't seen an update in eons. I'd recommend PF as it's syntax is almost the same as IPFilter so it should be relatively easy to convert.

- The IP address "172.18.9.218" is a local IP address that I was using to test the firewall. The FreeBSD machine runs an Apache server, and I was still able to access the "website" on the machine. Also, the machine responded to pinging, even after the ruleset file was reloaded.

That's actually simple. You are connecting to 172.18.9.218 while the firewall rules block traffic from 172.18.9.218. When dealing with firewall rules it is very important to understand the direction of the connection.

 

[LordInateur]

That's actually simple. You are connecting to 172.18.9.218 while the firewall rules block traffic from 172.18.9.218. When dealing with firewall rules it is very important to understand the direction of the connection.

I was pinging the FreeBSD machine from 172.18.9.218; I would have thought that the firewall would have blocked the ping from the external machine. I wasn't pinging that machine from FreeBSD. Let me clarify further:

There are two machines:

• Server, FreeBSD OS, IP N/A (I'm not with the machine right now)
• Client, Windows 7 OS, IP 172.18.9.218

I have set up the firewall on "Server" to block all incoming connections from "Client." Therefore, is it not correct that, if I issue a ping command on "Client" to "Server" that "Server" should deny the connection? Maybe I'm just not understanding you.

 

[fbsd1]

I need more details about your network configuration. Is the firewall machine also the gateway? I.e. the machine your ISP modem is wired to. Is there a LAN behind your firewall machine? Are there some other "options" you enabled in your kernel besides those for ipfilter? ipfilter works just fine using the GENERIC kernel. There is no reason for a special ipfilter kernel.

Your firewall rules

pass in all
pass out all

override the "default block all" you compiled into your kernel.

What do you mean by 'the IP address "172.18.9.218" is a local IP address'? That is a public routable IP address. Local means an IP address on a LAN behind the gateway machine. A LAN is supposed to use non-routable IP addresses from this reserved group 10.0.0.0, 172.16.0.0, and 192.168.0.0.

I have been using ipfilter since 3.0-RELEASE with no problems. It's rock hard and back level does not mean outdated or EOL. Last month ipfilter got a new maintainer and it's scheduled to be brought up to upstream version level and included in 10.0-RELEASE when it's published.

 

[LordInateur]

Is the firewall machine also the gateway? I.e. the machine your ISP modem is wired to. Is there a LAN behind your firewall machine?

No, it's at the very end of the line.

IS there some other "options" you enabled in your kernel besides those for ipfilter?

No, those are the only options that I added.

Your firewall rules

pass in all
pass out all

overrides the "default block all" you compiled into your kernel.

I understand, it's just there just in case I need to change something in the future.

What do you mean by "the IP address "172.18.9.218" is a local IP address"? That is a public routable IP address. Local means IP address on a LAN behind the gateway machine. A LAN is supposed to use non-routable IP addresses from this reserved group 10.0.0.0, 172.16.0.0, and 192.168.0.0.

Well, the network configuration is pretty messed up. It's located at a university (a college), where they've done something quite odd to the network setup to accommodate for everyone. Furthermore, I'm in a location where there's only WiFi (no Ethernet ports), so I had use my laptop as a sort of WiFi-Ethernet bridge, where the network enters through the wireless card and out through the Ethernet port, into the machine.

 

[ShelLuser]

Another IPFilter fan here

Just to make sure; what does # ipfstat -i tell you? That will make sure that any rules are actually in place.

Another handy command could be # ipfstat -t, this will show the state table and that could also give some indication as to what is going on at your end. Heck, merely running # ipfstat might give some clues too.

I'm also running a custom kernel, but still rely on ipl.ko.

(edit)

Looking at your kernel configuration and /usr/src/sys/conf/NOTES I can't help wonder why you didn't include IPFILTER_LOOKUP?

Note that I'm not an expert on this (as said, I rely on the kernel module) but it seems to me as if IPFilter support is made up of three options (excluding the optional block):

options         IPFILTER                #ipfilter support
options         IPFILTER_LOG            #ipfilter logging
options         IPFILTER_LOOKUP         #ipfilter pools
options         IPFILTER_DEFAULT_BLOCK  #block all packets by default

Just a wild guess on my part mind you.

 

[LordInateur]

Another IPFilter fan here

Just to make sure; what does # ipfstat -i tell you? That will make sure that any rules are actually in place.

Another handy command could be # ipfstat -t, this will show the state table and that could also give some indication as to what is going on at your end. Heck, merely running # ipfstat might give some clues too.

I'm also running a custom kernel, but still rely on ipl.ko.

(edit)

Looking at your kernel configuration and /usr/src/sys/conf/NOTES I can't help wonder why you didn't include IPFILTER_LOOKUP?

Note that I'm not an expert on this (as said, I rely on the kernel module) but it seems to me as if IPFilter support is made up of three options (excluding the optional block):

options         IPFILTER                #ipfilter support
options         IPFILTER_LOG            #ipfilter logging
options         IPFILTER_LOOKUP         #ipfilter pools
options         IPFILTER_DEFAULT_BLOCK  #block all packets by default

Just a wild guess on my part mind you.

Hello,

Sorry for the late response, I've been very busy. When I get the machine back up, I'll redo IPFILTER and let you know what the output of ipfstat -i is, again after I put it back together. Thank you for your time!