Well, if the rule itself is hard-coded, then you are not protected unless you manually change the rule.  If the rule, for example, said something like $FTP_PORTS instead of "21", then you would be protected.  Unfortunately we are somewhat at the mercy of the rule writers from both Emerging Threats and Snort VRT.

So it sounds like in your particular case, you might be better off using the default FTP port instead of an alternate one.  The only other fix I can think of would be to manually edit the affected rules, but then at the next rules update you would have to do it again.

Bill

No sorry, already tried that and it didnt work…

If i may add, this seems to happen only in IE. Chrome works fine.

I'm having issues with sarg reports too. Also my realtime view stopped working since i updated to the latest 2.1 beta yesterday. I was on 2.0.2 before and at least the realtime view was working. but now with 2.1 beta i can get havp + squid working, so I think there's some tweaking for the realtime view to work again with taht new configuration, not sure.

I am concerned about the "Exit Code 127" errors.  I cannot find a definition for that error and I have tried running the commands by hand, but do not get those errors.

the same rule is valid also for http but sgerror page is displayed

my rules just prevets bypassing proxy and block direct connect to http, https or ftp . clients can access theese protocols if they use proxy

the problem is the port, currently it allows only listening to one port and to truly make it work would need some work

I just confirmed - the alarm FAILS to trigger a filter update for ANY time crossing even though the SquidGuard log shows that the alarms are being calculated:

2013-03-05 14:02:43 [25967] squidGuard ready for requests (1362513763.536)
2013-03-05 14:02:43 [26036] squidGuard 1.4 started (1362513763.329)
2013-03-05 14:02:43 [26036] Info: recalculating alarm in 737 seconds
2013-03-05 14:02:43 [26036] squidGuard ready for requests (1362513763.558)
2013-03-05 14:02:43 [26132] squidGuard 1.4 started (1362513763.689)
2013-03-05 14:02:43 [26132] Info: recalculating alarm in 737 seconds
2013-03-05 14:02:43 [26132] squidGuard ready for requests (1362513763.764)

VERIFIED: The change FAILS for both ON/OFF transition and OFF/ON transition.

@rubic:

@jimp:

That may be a completely separate error from this.

I think the error is this commit related. While Quagga OSPF 0.99.20.1 v0.5.0 works fine in my production environment, in my fresh test setup with Quagga OSPF 0.99.20.1 v0.5.1 any value in the "Disable Redistribution" field prevents the service to start.

Ah this way I can try it, too:

[2.1-BETA1][root@fw1.zws8.local]/root(134): /usr/local/bin/quaggactl start
There is no such command.
Error occured during reading below line.
  distribute-list dnr-list out connected

mmmh… I've tested my patch and it worked with several config modifications/reboots in my test setup... so a little surprising that it's now damaging OSPF package... sorry.

Without my above fix it works again.

router ospf   ospf router-id 192.168.6.3   log-adjacency-changes detail   redistribute connected   redistribute static   network 192.168.6.0/24 area 192.168.6.0   distribute-list dnr-list out connected   distribute-list dnr-list out kernel   distribute-list dnr-list out static   access-list dnr-list deny xx.xx.176.0/24   access-list dnr-list permit any

One problem / unknown difference:
I have one stable/old pfSense 2.0.1 pair and actual pfSense 2.1-BETA1 pair on other side…
The stable version didn't redistribute the network:

[2.0.1-RELEASE][root@fw1.jws1.local]/root(133): vtysh

Hello, this is Quagga (version 0.99.20.1).
Copyright 1996-2005 Kunihiro Ishiguro, et al.

fw1.jws1.local# sh ip route
Codes: K - kernel route, C - connected, S - static, R - RIP, O - OSPF,
      I - ISIS, B - BGP, > - selected route, * - FIB route

K>* 0.0.0.0/0 via 91.102.12.193, lagg0_vlan2
O  xx.xx.176.0/24 [110/20] via 192.168.6.12, lagg1_vlan6, 00:31:09
                            via 192.168.6.13, lagg1_vlan6, 00:31:09
C * xx.xx.176.0/24 is directly connected, vip47
C>* xx.xx.176.0/24 is directly connected, lagg0_vlan7
C>* xx.xx.176.4/32 is directly connected, vip40
C>* xx.xx.176.7/32 is directly connected, vip49
…

but BETA does?

[2.1-BETA1][root@fw1.zws8.local]/root(139): vtysh

Hello, this is Quagga (version 0.99.21).
Copyright 1996-2005 Kunihiro Ishiguro, et al.

fw1.zws8.local# show ip route
Codes: K - kernel route, C - connected, S - static, R - RIP,
      O - OSPF, I - IS-IS, B - BGP, A - Babel,
      > - selected route, * - FIB route

K>* 0.0.0.0/0 via xx.xx.176.254, lagg0_vlan7
O  xx.xx.176.0/24 [110/20] via 192.168.6.13, lagg0_vlan6, 00:24:14
C * xx.xx.176.0/24 is directly connected, opt14_vip120
C * xx.xx.176.0/24 is directly connected, opt14_vip117
C * xx.xx.176.0/24 is directly connected, opt14_vip103
C * xx.xx.176.0/24 is directly connected, opt14_vip119
C * xx.xx.176.0/24 is directly connected, opt14_vip118
C * xx.xx.176.0/24 is directly connected, opt14_vip116
C * xx.xx.176.0/24 is directly connected, opt14_vip115
C * xx.xx.176.0/24 is directly connected, opt14_vip114
C * xx.xx.176.0/24 is directly connected, opt14_vip109
C>* xx.xx.176.0/24 is directly connected, lagg0_vlan7
…

I tested before only with BETA versions… and got problems with public routing.
(1st firewall pair got .1/.2/.3, 2nd fw pair .254/.253/.252)
Because without this "Disable Redistribution" of this public network the firewalls didn't saw itselfes and therefore shutting down their gateways.

ah... different BSD package versions which causes the problem:
2.0.1        => Hello, this is Quagga (version 0.99.20.1).
2.1-BETA1 => Hello, this is Quagga (version 0.99.21).

so please remove my patch… and we must search for other places to patch the behavior in package for 2.1...
Thanks.

Bests

Reiner

Reinstalling the xml worked at least in one installation. Thx!

I have been able to build squid 3.3 on a FreeBSD 8.3 machine and it seems to work ok with a few minor changes.  Even working with squidguard.

Needed a few things like the ssl-bump-server-first feature and dynamic certificate generation, plus the request_header_add option.

I've been attempting this http://support.google.com/a/bin/answer.py?hl=en&answer=1668854 but haven't quite managed it yet.

I built the squid32 port which pulled all the build dependencies then built 3.3.1 from source.

What's wrong with it using squid custom options?!

Thats a good question… It has been a long journey with Snort since it has a lot of problems with PfSense. You helped to make the package significantly better and that helped a lot!

A fair guess would be after we had the last discussion and I implemented your fixes.

Thank you. I found it. Thanks.

hi peter, ı think ı have made a mistake in number 4.You should enter your lan subnet as ''source' like 10.0.0.0/24

and dont forget that ''–--'' means your 'default access' setting (allow or deny) in common acl section, if you set it to 'deny', any '----' in your acl's will mean 'deny'

here are my settigs that works

-I have local user uathentication
-ın common acl all  categories are allowed
-one group acl for limited (will be blocked) categories for lan subnet 'source' (ex: 10.0.0.0/24)
-one group acl allowing all categories for unlimited users(in source section like 'user1' 'user2' )  at the top in 'order' section'

so if the user is defined in unlimited group acl the first rule takes over and he gets all access
if not second rule takes over and filter rules applied for the 10.0.0.0/24 subnet regardless of username

NOTE:be sure that clients use proxy (via manuel browser configuraton or wpad)