Solved [Solved] Blocked packets in ipfilter after upgrade to 10

Took me a while to realize as my provider also had problems with upstream speed. Running now FBSD10 FreeBSD 10 on a HP microserver with ipfilter/ipmon enabled. Sending out TCP traffic results in blocked packets being logged with ipmon:

Code:
ug 19 16:19:51 netdb ipmon[885]: 16:19:51.276031 em0 @0:6 b 213.193.121.99,9418 -> 213.193.121.98,42174 PR tcp len 20 2948 -A OUT bad
Aug 19 16:19:51 netdb ipmon[885]: 16:19:51.276067 em0 @0:6 b xxx.xxx.121.99,9418 -> xxx.xxx.121.98,42174 PR tcp len 20 2948 -A OUT bad
Aug 19 16:19:51 netdb ipmon[885]: 16:19:51.979947 em0 @0:6 b xxx.xxx.121.99,9418 -> xxx.xxx.121.98,42174 PR tcp len 20 2948 -A OUT bad
Aug 19 16:19:52 netdb ipmon[885]: 16:19:52.685548 em0 @0:6 b xxx.xxx.121.99,9418 -> xxx.xxx.121.98,42174 PR tcp len 20 2948 -A OUT bad
Aug 19 16:19:52 netdb ipmon[885]: 16:19:52.685594 em0 @0:6 b xxx.xxx.121.99,9418 -> xxx.xxx.121.98,42174 PR tcp len 20 2948 -A OUT bad

This is not only true for Git, but also for web, FTP whatever The rules are defined like on version 9 before:

Code:
pass in quick on em0 proto tcp from xxx.xxx.121.96/29 port > 1023 to xxx.xxx.121.99/32 port = 9418 flags S/SA keep state keep frags

From the poor log message documentation I've found on ipmon, the packet sizes are over 1500. So I'm not sure if those values should be <= 1500 or not, instead of 2948.
 
Re: Blocked packets in ipfilter after upgrade to 10

I suggest using IPFW or PF instead. The IPFilter code hasn't seen an update in eons.
 
Re: Blocked packets in ipfilter after upgrade to 10

Switched now to PF....works like a charm now (o;

Hope I have configured it right according to the old ipfilter rules ;-)

Now just git_daemon needs fixing....
 
Re: Blocked packets in ipfilter after upgrade to 10

davorin said:
Hope I have configured it right according to the old ipfilter rules ;-)
Should be simple enough, the syntax is almost the same ;)
 
Hmm..looks similar to ipfilter...

Just wonder why it won't let DNS udp/tcp in:

Code:
 pass in log on $ExtIf inet proto udp  from ($ExtIf)            to xxx.xxx.121.99/32 port 53  $UdpState
 pass in log on $ExtIf inet proto tcp  from ($ExtIf)            to xxx.xxx.121.99/32 port 53  $TcpState $SmtpSTO

Git pull from outside works now in full speed...
 
Stupid me (o;

Two things....

Should read !($ExtIf) and not ($ExtIf)....misinterpreted this as "anything coming in from this interface"....but probably means "anything coming from the IP range this interface is configured in"...

And second: Didn't comment out in named.conf
Code:
//      listen-on       { 127.0.0.1; };


Hmm...just checked....!($ExtIf) allows traffic coming from same subnet as ($ExtIf) is in....


Seems port number names aren't extracted from /etc/services....so can't use port git although it's defined in services....

But apart from the above points....much better ways to write rules....especially defining arrays for networks...so it can be easily extended/reduced with just a line and not going through every rule if I haven't forgotten something (o;
 
I've seen several methods so far today...still learning (o;

"service pf reload" ???? Reminds me the Debian way (o;

What I still don't get is how it interprets the "($ExtIf)" statement....is it always the configured IP with /32 or the configured IP with configured netmask?
 
davorin said:
I've seen several methods so far today...still learning (o;

"service pf reload" ???? Reminds me the Debian way (o;

What I still don't get is how it interprets the "($ExtIf)" statement....is it always the configured IP with /32 or the configured IP with configured netmask?

The ($Extif) construction tells PF to use the IP address assigned to Extif but keep track of changes to the address in case it changes with DHCP. Without the parentheses around $Extif you would have to do service pf reload manually every time the addresses(es) on Extif change.
 
Regarding IPF not being updated in ages, this is 10's svn log sbin/ipf for the record. Chances are there was behavior change somewhere along the way that got you.

Code:
r255332 | cy | 2013-09-06 23:11:19 +0000 (Fri, 06 Sep 2013) | 5 lines
Update ipfilter 4.1.28 --> 5.1.2.
Approved by:            glebius (mentor)

Regarding the service pf reload behavior, that will not flush states from the state table so you maintain your connection. Other commands will flush states and drop a connection.

Regarding the ($Extif) parsing, take a quick look at the pf.conf() man page. Specifically, man pf.conf | less -p :network will get you to the section about the different suffixes you can put on and what they do.
 
I wonder where they got it from. The mailing list seems to have died a slow death somewhere in in 2012. Although 5.1.2 does appear to be the latest version I'm doubtful there's any active development going on. http://marc.info/?l=ipfilter
 
Hello,

I experience exactly the same issue with FreeBSD 10-STABLE built last night. Initially thought it was because of VMXNET3 adapter and all sorts of checksums but it doesn't seem to be the case. Does it make sense to submit a bug report?

Thanks.
 
I am also experiencing problems with IPFilter. Specifically ipnat. I only use ipnat really, my firewall rules are to pass everything. On FreeBSD 8.3, 8.4, 9.2 I have had no problems with ipfilter/ipnat. I use exactly the same config on FreeBSD 10.0 and I have major problems. Basically, it works fine after a reboot. But after a couple of days, it degrades to a point where half the ping attempts from a LAN client get a "no route to host" error. It effects Thunderbird more than web surfing.

This the crucial info from output of ipfstat:
Code:
114     output block reason IPv4 NAT failure

This is after a few hours of use. But after a day or two the number of blocks due to NAT failure goes into the thousands.

The next time it gets really bad (tomorrow or day after) I will try to remember to post the full ipfstat.
 
Apparently they sneaked in an update for IPF on FreeBSD 10.0 to update it to the last version. IPFilter 5.1.2 was released in 2012. I still recommend switching to either IPFW or PF due to the lack of active development.

If you really want to keep using IPF I suggest submitting a bug report.
 
Yep, I'm looking into IPFW. I only use IPFilter because I was using it in Solaris 10, before I switched to FreeBSD. It allowed me to migrate easier, and I know and trust ipfilter. It's a shame, it was rock solid prior to 10.0.

The IPFW section of the handbook looks fairly straight forward to get going. I think pf may be overkill for a simple NAT router, with a few port forwards. I tried it once, it didn't play well with Jitsi voice calling (via XMPP), whereas ipfilter worked fine. Once I set[]up pf with UPNP, Jitsi worked. However, it was not straight-forward to set[]up, and I was left thinking I need to learn much more about pf before feeling comfortable with it. I like ipfilter's simplicity.
 
ethoms said:
Once I set[]up pf with UPNP, Jitsi worked. However, it was not straight-forward to set[]up, and I was left thinking I need to learn much more about pf before feeling comfortable with it. I like ipfilter's simplicity.
You may want to have a look at net/miniupnpd. It works rather well in combination with PF. My Windows clients can dynamically open and forward ports. Configuration is fairly simple. You just need to add two lines to your /etc/pf.conf:
Code:
rdr-anchor "miniupnpd"

anchor "miniupnpd"

Lines will be dynamically added and removed by miniupnpd. After a while you get something that looks like this:
Code:
root@maelcum:~ # pfctl -sr -a miniupnpd
No ALTQ support in kernel
ALTQ related functions disabled
pass in quick on re0 inet proto udp from any to 192.168.10.47 port = 9000 flags S/SA keep state label "Ubisoft 94-DE-80-2D-40-04" rtable 0
pass in quick on re0 inet proto tcp from any to 192.168.10.87 port = mmcc flags S/SA keep state label "SEC_NATT_192.168.10.87:5050" rtable 0
pass in quick on re0 inet proto udp from any to 192.168.10.64 port = 31243 flags S/SA keep state label "RaceRoom Racing Experience multiplayer (192.168.10.64)" rtable 0
pass in quick on re0 inet proto udp from any to 192.168.10.64 port = 55444 flags S/SA keep state label "Teredo" rtable 0
pass in quick on re0 inet proto tcp from any to 192.168.10.47 port = 47995 flags S/SA keep state label "GameStream" rtable 0
pass in quick on re0 inet proto tcp from any to 192.168.10.47 port = 47996 flags S/SA keep state label "GameStream" rtable 0
pass in quick on re0 inet proto tcp from any to 192.168.10.47 port = 35043 flags S/SA keep state label "GameStream" rtable 0
pass in quick on re0 inet proto tcp from any to 192.168.10.47 port = 47989 flags S/SA keep state label "GameStream" rtable 0
pass in quick on re0 inet proto tcp from any to 192.168.10.47 port = 47984 flags S/SA keep state label "GameStream" rtable 0
pass in quick on re0 inet proto tcp from any to 192.168.10.47 port = 48010 flags S/SA keep state label "GameStream" rtable 0
pass in quick on re0 inet proto udp from any to 192.168.10.47 port = 47999 flags S/SA keep state label "GameStream" rtable 0
pass in quick on re0 inet proto udp from any to 192.168.10.47 port = 47992 flags S/SA keep state label "GameStream" rtable 0
pass in quick on re0 inet proto udp from any to 192.168.10.47 port = 47998 flags S/SA keep state label "GameStream" rtable 0
pass in quick on re0 inet proto udp from any to 192.168.10.47 port = 48000 flags S/SA keep state label "GameStream" rtable 0
pass in quick on re0 inet proto udp from any to 192.168.10.47 port = 47989 flags S/SA keep state label "GameStream" rtable 0
 
Thanks @SirDice. I think it was miniupnp that I used previously. However I remember having to set something else up as well. I just remember it was not that simple. Perhaps I was very busy and so it seemed more work than it really was. I just remember feeling overwhelmed with pf, and decided to keep it simple and stick to ipfilter.

I think I'll try ipfw first. Then if it doesn't fit my needs, I'll adopt pf.
 
Last edited by a moderator:
Back
Top