Ignore me  :o

I have a small error in my code (OK major), which is saving my log files a day behind….

All the IP's I see were yesterdays.

@cthurner:

Hello,

thanx for your reply. I have used the radtest tool on the command line to test the OTP authentication as described here https://doc.pfsense.org/index.php/FreeRADIUS_2.x_package. As password I have used the OTP that has been created by DroidOTP on my
Android phone. I don't think I have mistyped anything. Furthermore I have compared the otpverify.sh from http://motp.sourceforge.net/bash/otpverify.sh
with the version provided by the freeradius2 package. The original script uses "OTP=printf $EPOCHTIME$SECRET$PIN|checksum|cut -b 1-6" (in line 104)
whereas the freeradius version uses "OTP=printf $EPOCHTIME$SECRET$PIN|checksum|cut -b 6". In my understanding the second version is wrong, as it only
uses the 6th character instead of the first 6 characters. Therefore any authentication request via radius will be rejected. With my modifaction it works. So I think this is indeed a bug.

CU

Christian

I try to explain it again for you.
On the GUI YOU probably typed:

6

This is "wrong" because it only uses character 6 (just one character)

On the GUI you MUST type:

1-6

This uses characters 1, 2, 3, 4, 5, 6

TCP does not have a notion of a "request". TCP is just a binary stream of data, like a file stream. What you would need is a reverse proxy that could forward based on mysql protocol.

My guess is this has not been done as it sounds like there is a better way to handle this, but I could be wrong. Hopefully someone can help you with if this can be done.

If your WAN IP is public, DynDNS will let you reach it.

If your WAN IP is private and you control your modem/router ahead of you, then set it to pass the traffic into your pfSense (e.g. port forward, "DMZ", etc) and you can still use DynDNS.

If your WAN IP is private and your ISP is performing Carrier-Grade NAT then in all likelihood you have no way to receive inbound traffic for remote management.

If you have another location that has a public address, you could do a site-to-site tunnel to there, and then have a remote access VPN connect to that and hop across a site-to-site VPN to reach the router that's stuck behind NAT.

I had the same issue, i386 version though. After two retries it worked for me.

@percyiii:

fetch -o /usr/pbi/dansguardian-amd64/sbin/dansguardian "http://e-sac.siteseguro.ws/pfsense/8/amd64/dansguardian"

save one of the dansguardian pages..
check make sure it started…
check make sure the web ulpload is now working

Now the how-to had fetch to e-sac.siteseguro.ws going into /usr/local/sbin
/usr/local/sbin is symlinked to /usr/pbi/dansguardian-amd64/.sbin/dansguardian
But the only way I could get it to work was to fetch to /usr/pbi/dansguardian-amd64/sbin not .sbin..
Does Dans use both executables?
Whick one runs?

I fetch to  /usr/pbi/dansguardian-amd64/sbin  which seems to work fine for me.

This has been answered in previous forum posts:

https://forum.pfsense.org/index.php?topic=43154.0

https://forum.pfsense.org/index.php?topic=64264.0

https://forum.pfsense.org/index.php?topic=54180.0

https://forum.pfsense.org/index.php?topic=48139.0

etc etc

In the menu, look at Services - proxy filter.  From there, use Times to create your schedule.  Then go to Groups ACL to create groups of IP addresses and what they are allowed to access, and link them to the schedule.

https://forum.pfsense.org/index.php?topic=18714.msg96295#msg96295

same probem with me  , but still no solution . btw after restart it will be false again . and my will be like this
"can't connect to clamd: No such file or directory"

i fix using this

mkdir /var/run/clamav
ln -s /var/run/clamd.pid /var/run/clamav/clamd.pid
ln -s /var/run/clamd.sock /var/run/clamav/clamd.sock

every reboot

I'd be interested in how to do this too??

@BBcan177:

I would suggest that you block all outgoing LAN DNS requests unless they are originating from your DNS Server(s) or pfSense DNS apps.

This is a very effective way to handle the potential issue.  Restrict all LAN DNS traffic to just your internal DNS server (or servers), then further restrict outbound DNS (on WAN) to designated forwarders.

There are some DNS policy rules in the Emerging Threats family that can help as well, but in my view the easiest method is restricting outbound DNS to only authorized hosts.

Bill

I'm no expert either.  I just try to help people if I can.

To get to the log, first login to the shell (option 8 in the pfSense text menu).

From there, go to /var/log and look for squidGuard.log.  Maybe take a look at the system.log while you're at it.

I can't even begin to tell you what to look for other than obvious errors.

1.2.3 is no longer supported. Squid+SquidGuard on NanoBSD on 1.2.3 even less so.

There could be some remnant of a past installation somewhere on the drive in /usr/local/pkg/ or in the config.xml that needs cleaned out. Not enough info to say, but you should really be running the latest version (2.1.x) and not 1.2.x.

It is a pity that I did not get any answer…  :'(

Havp seems to be running, although I can see many log entries.

havp[35911]: connect() failed: Address family not supported by protocol family
havp[78165]: connect() failed: Operation not permitted
havp[19896]: connect() failed: Address family not supported by protocol family

Updated to pkg 2.2.5 yesterday, Squid refuses to start. However the error message has changed, it is now :

php: /status_services.php: The command '/usr/local/etc/rc.d/squid.sh stop' returned exit code '1', the output was '2014/06/10 13:23:33| parse_peer: token='round-robinssl' FATAL: Bungled /usr/pbi/squid-i386/etc/squid/squid.conf line 98: cache_peer 10.0.0.10 parent 443 0 proxy-only no-query no-digest originserver login=PASSTHRU round-robinssl sslflags=DONT_VERIFY_PEER front-end-https=auto name=rvp_exchange Squid Cache (Version 3.3.10): Terminated abnormally. CPU Usage: 0.015 seconds = 0.007 user + 0.007 sys Maximum Resident Size: 29312 KB Page faults with physical i/o: 0'

and then :

squid: Bungled /usr/pbi/squid-i386/etc/squid/squid.conf line 98: cache_peer 10.0.0.10 parent 443 0 proxy-only no-query no-digest originserver login=PASSTHRU round-robinssl sslflags=DONT_VERIFY_PEER front-end-https=auto name=rvp_exchange

Obviously there is some code in the config pointing to a server that does not exist any more. Can I delete this line ? I could not find any point in
the GUI pointing to this retired server and I have never configured a chache_peer.

Thank you for your hints

cheers thafener

Sorry everyone…

Bump

@jflsakfja:

Bug:

Blocked tab:
Warning: inet_pton(): Unrecognized address TCP in /usr/local/www/suricata/suricata_blocked.php on line 247 Warning: inet_pton(): Unrecognized address TCP in /usr/local/www/suricata/suricata_blocked.php on line 247

Rule that caused it:
files.rules:
1:22 FILE pdf claimed, but not pdf <<< fires up when spiders (eg googlebot) try to download a part of a pdf, therefore DELETE UPSTREAM (part after <<< is in the upcoming suricata topic)

It also breaks the alerts tab, with text all over the place.

Thanks for the report.  I will add this to my list.  I'm holding the next Suricata hoping the Ports tree on FreeBSD will soon update to the 2.0.x Suricata branch.

Bill

KOM

I use the no-transparent mode to block internet connection  in a user