Home » Forums » Community Edition » Open Discussion

pfSense - Fail2ban -- QOS/TOS Values

jdwebcc
Posts: 149
 Member Since:
2006-09-27
Submitted by jdwebcc on Fri, 01/15/2010 - 2:38pm.

Thought everyone should know a issue I found.

Installing fail2ban -- caused a raised condition where pfSense was not shaping the voip traffic properly. pfSense version 1.2.3 RC2 -- does not shape properly that it does not ignore the TOS settings as set in the rule when creating it.

What happens is installing fail2ban somehow starts marking the packets differently even if you set this option in asterisk.. thus the traffic don't get shaped. Now using version 1.2.1 RC4 is fine.

I found removing fail2ban when using pfSense 1.2.3 RC2 -- allowed the settings set by Asterisk to be seen by pfSense and then my calls were shaped correctly again.

This came when a client called complaining that customers couldn't hear them... so I looked at the traffic queues and during a call the outbound call leg wasn't getting shaped... stopping fail2ban finally resolved it. I pulled my hair out making every change I could to the conf files but the packet capture showed that the values were not changing.. it was only after hours did I realize the last change to this customer was fail2ban.

I stopped fail2ban - iptables and made a test call and bam.. now calls are shaped right ! OMG -- talk about frustration.

If you want to use fail2ban -- it would be easier to just use pfSense 1.2.1 RC4

That is my two cents.

JD

‹ WARNING!! trixbox is vulnerable to SQL injection!! Intelligent call routing and CRM integration ›
--

Jason S Derr, JDWEB.cc LLC
Creator of ASR Manager


&nbsp

b14ck
Posts: 773
 Member Since:
2009-03-03
Hi Jason, fail2ban does not
Fri, 01/15/2010 - 10:06pm

Hi Jason,

fail2ban does not modify packets in any way, it only parses log files, and then creates IP tables rules to block traffic from specific IP addresses. Can you please post some detailed packet information so I can help troubleshoot the root cause? There should be no issue, if there is, then there is likely something mis-configured with your iptables setup.

--

Randall Degges
Lead Developer, RCI Telecommunications
projectb14ck - http://projectb14ck.org/ - Weblog


&nbsp

jdwebcc
Posts: 149
 Member Since:
2006-09-27
Didn't say who was doing - only what was happening
Tue, 02/02/2010 - 4:56am

I didn't say specifically that fail2ban modifies the packets.. only the end result. I since have figured out it is iptables doing it... and fail2ban installs and configures iptables causing the issue.

I wasn't doing any additional configuration just installing fail2ban using install-fail2ban --

We tried even changing the TOS values in asterisk -- but the packet capture showed the packet values stayed the same. Only after stopping fail2ban and iptables did we then see the packet tos values change to what we had set in the sip_general_custom.conf and thus get shaped properly.

Another odd thing is I have about 18 premise boxes - we were not seeing it on all of them. They all are yum updated to the same version... only about 5 of the installs (which were the latest ones) had the issue... and the issue only came on shortly after learning about fail2ban and using the Trix included script to install it.

I merely just went back to pfSense 1.2.1 RC4 and didn't see the issue eitherway..

--

Jason S Derr, JDWEB.cc LLC
Creator of ASR Manager


&nbsp

b14ck
Posts: 773
 Member Since:
2009-03-03
fail2ban does not configure
Tue, 02/02/2010 - 9:37am

fail2ban does not configure IPtables at all. It only turns it on. If it detects (by parsing log files) that there was a brute force attempt, it will create an IPtables rules to block all incoming packets from that IP address. Also--you can (at anytime) flush the IPtables running rules to effectively cancel any rules that IPtables added.

Also, on trixbox CE servers, the settings in sip.conf for TOS packet settings have no effect. This is because on trixbox CE Asterisk runs as the user 'asterisk' to prevent security issues. Those TOS settings will only take effect if Asterisk is running as the root user (as modifying the raw packets requires root access).

One thing you may want to do is dump your running IPtables config to http://pastie.org/ and then paste a link in this thread. That may make it easier for us to help troubleshoot the issue. There may be some other software running or you may have some pre-defined IPtables rules mucking up your networking :)

--

Randall Degges
Lead Developer, RCI Telecommunications
projectb14ck - http://projectb14ck.org/ - Weblog


&nbsp

jdwebcc
Posts: 149
 Member Since:
2006-09-27
Again - not interested in the who and where only how to get past
Tue, 05/04/2010 - 4:15pm

Using the script that was packaged with Trix CE -- it would install both fail2ban & iptables... at the same time while running pfSense 1.2.2 or higher - the VOIP traffic was going into the wrong queue.

We already figured out how to resolve it.. one way is to modify the iptables rules to properly mark the packets so that pfSense segregates them properly. Or the other which is the route I went was to just use 1.2.1 RC4 as it properly ignores the TOS values as I stipulate the traffic I want low delay by origination & destination IP.

The second resolution is the best in other case scenarios too -- as I have installed in lots of locations where the generic modem used was also remarking the packets improperly thus pfSense wouldn't put them in the right queue.. using 1.2.1 RC insures they get put into the queues I want and handled appropriately.

--

Jason S Derr, JDWEB.cc LLC
Creator of ASR Manager


&nbsp

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.