Yes.  The Suricata package will decode and log all HTTP traffic.  You can see the source/destination address and the exact URL that is being requested.  Everything is timestamped.  However, it is a 'raw' log and will require some manipulating to pull it into a more readable format. Another alternative is Netflow.  Export the data to a Netflow collector and you can see the conversations, but not the actual URL's being requested. Another less informative alternative is to use OpenDNS.  You can generate reports on what domains are being requested, but not from which machine and the report is only on a full-day basis. EDIT:  The squid solution posted above would be a very good way to accomplish what you want.

Are you able to ping from a SEC device to a DMZ device? What about from the DMZ interface to the SEC network (within pfSense in Diagnostics -> Ping)?

@jimp: Sounds like either ntop is running multiple times, or you have a clock issue causing ntop to believe the clock is stepping backward or not ticking properly. Time zone set  Europe/Athens from console-terminal  is ok. Must to configure and ntop time ? seperetely ?

I assume you want to do this to backup your configs. All you need to do is setup an FTP server on the backup target and use this script: #!/bin/bash HOST=IP  #This is the FTP servers host or IP address. USER=USER            #This is the FTP user that has access to the server. PASS=PASS        #This is the password for the FTP user. dstamp=date +%Y-%m-%0e cd /cf/conf Call 1. Uses the ftp command with the -inv switches.  -i turns off interactive prompting. -n Restrains FTP from attempting the aut o-login feature. -v enables verbose and progress. ftp -inv $HOST << EOF Call 2. Here the login credentials are supplied by calling the variables. user $USER $PASS Call 3. Here you will change to the directory where you want to put or get cd /cf/conf/ Call4.  Here you will tell FTP to put or get the file. put config.xml chmod 777 config.xml rename config.xml config$dstamp.xml or #get test.txt bye EOF i have this on a daily cronjob and it works very well.

It seems you have connected your pfSense to an existing network. pfSense sets the LAN IP to 192.168.1.1 by default. For existing networks this would not fit. At first you may to configure the LAN interface on the shell and assign an unique IP in your network. Then you get access to the web interface.

Bridge what connections? What do you think you need to bridge?

@Harvy66: I'm just going to wait for 2.2 stable, then try it out again. Might take quite some time. Meanwhile, snaps seem to be back.

There is a new advanced option in 2.1 that will allow the creation of a RAM disk to store logs on. It is documented somewhere, just search for it.

It sounds like the transparent proxy is blocking port 443 which the game login might be using to authenticate. You either need to apply the proxy settings in the game itself or create an exception in the firewall rules for the game server IP address. Just my thoughts. Look at this post: https://forum.pfsense.org/index.php?topic=62256.msg405719#msg405719  and reply #243. This should also work for your situation.

Reinstall the box.

Some random lawyer sending your bills doesn't sound to me like something that stands any ground. In switzerland there are various places to get help with situations like this. I'm sure in germany there are similar agencies available (see http://www.beobachter.ch/justiz-behoerde/gesetze-recht/artikel/rechtsstreitigkeiten_rechtsberatung-zum-nulltarif/ )