As far as I know auto-update will only update existing files and add new files to the system but it will not remove "old" files if these are not used anymore.

Further if you are using pfsense 2.0.x with packages and then 2.1.x with packages then I would suggest to do a fresh installation because the way how packages are handled on pfsense 2.1 is different. It will work if you are using auto-update but then it could be possible that you have old pfsense 2.0.x package files left on the system and then install the packages the pfsense 2.1 way.

And if you played much with packages, installed some for testing and uninstalled them again and so on there could be fragments left.
So I personally go the way to do a fresh install until I know what I want to use and install. If I am just testing I am using the auto-update fuction.

Thanks for replying. It's not that import for me, so I guess I am going to wait until 2.2 becomes stable, as I don't want to break my rock solid installation

Thank you, created one.

IPsec has better third party support.

OpenVPN is easier to use, more likely to punch out of random remote networks, and less prone to have problems with renegotiation.

You can do L2 or L3 on either one. IPsec can do transport mode and encrypt anything between the WAN IPs, including some other tunneling protocol that does L2 such as GIF. OpenVPN has tun mode for that, which is much easier to deal with and easier to find client support for of course. :-)

I prefer OpenVPN anywhere I can use it. Especially now that there are clients for Android and iOS that don't require root/jailbreak.

Yes, It seems to work fine and as expected.  I didn't notice the DHCP status page showing multiple entries until I was off-site and looking at them remotely, and so could not check.  I have since gone past the site and checked, and all seems to work just fine.

Thanks.

From their site:

You can open the following ports to make Camfrog Server work behind a firewall/NAT.
Camfrog Server:
Please open following ports:
TCP 6005 — incoming port for client data connections
UDP 5000 – 15000 — incoming ports for multimedia streams
Camfrog Client:
Opened ports are not needed, but disable the firewall because it can cause conflicts.

Also from this site:
http://forum.pfsense.org/index.php?topic=17693.0

The issue mentioned in the second post isn't relevant in 2.x if you leave the "Filter rule association" option alone when creating the NAT forward.

I'm attaching here a tcpdump of a failing ssh attempt to a remote host.
The dump has been captured from within pfsense's VM, lan_host is a client on the lan and remote_host is the ip i'm trying to ssh to.

Apparently at 13:54:06.552208 the remote host replies with ACK, but the connection is not established.

What could be the problem?

tcpdump -nn -v host remote_host tcpdump: listening on em0, link-type EN10MB (Ethernet), capture size 96 bytes 13:54:04.355722 IP (tos 0x0, ttl 64, id 43641, offset 0, flags [DF], proto TCP (6), length 52)     lan_host.51155 > remote_host.30022: Flags [F.], cksum 0x9517 (correct), seq 1051905475, ack 4183675913, win 115, options [nop,nop,TS val 2397103 ecr 1808805240], length 0 13:54:04.865743 IP (tos 0x0, ttl 64, id 48162, offset 0, flags [DF], proto TCP (6), length 60)     lan_host.51231 > remote_host.30022: Flags [s], cksum 0x1d11 (correct), seq 1526999052, win 14600, options [mss 1460,sackOK,TS val 2397230 ecr 0,nop,wscale 7], length 0 13:54:05.863110 IP (tos 0x0, ttl 64, id 48163, offset 0, flags [DF], proto TCP (6), length 60)     lan_host.51231 > remote_host.30022: Flags [s], cksum 0x1c17 (correct), seq 1526999052, win 14600, options [mss 1460,sackOK,TS val 2397480 ecr 0,nop,wscale 7], length 0 13:54:05.992162 IP (tos 0x0, ttl 64, id 43642, offset 0, flags [DF], proto TCP (6), length 52)     lan_host.51155 > remote_host.30022: Flags [F.], cksum 0x937e (correct), seq 0, ack 1, win 115, options [nop,nop,TS val 2397512 ecr 1808805240], length 0 13:54:06.550870 IP (tos 0x0, ttl 53, id 0, offset 0, flags [DF], proto TCP (6), length 60)     remote_host.30022 > lan_host.51231: Flags [S.], cksum 0xa275 (correct), seq 1291086062, ack 1526999053, win 14480, options [mss 1412,sackOK,TS val 1808882048 ecr 2397230,nop,wscale 5], length 0 13:54:06.552208 IP (tos 0x0, ttl 64, id 48164, offset 0, flags [DF], proto TCP (6), length 52)     lan_host.51231 > remote_host.30022: Flags [.], cksum 0x0787 (correct), ack 1, win 115, options [nop,nop,TS val 2397652 ecr 1808882048], length 0 13:54:07.547636 IP (tos 0x0, ttl 53, id 0, offset 0, flags [DF], proto TCP (6), length 60)     remote_host.30022 > lan_host.51231: Flags [S.], cksum 0xa17c (correct), seq 1291086062, ack 1526999053, win 14480, options [mss 1412,sackOK,TS val 1808882297 ecr 2397230,nop,wscale 5], length 0 13:54:07.548634 IP (tos 0x0, ttl 64, id 48165, offset 0, flags [DF], proto TCP (6), length 52)     lan_host.51231 > remote_host.30022: Flags [.], cksum 0x068e (correct), ack 1, win 115, options [nop,nop,TS val 2397901 ecr 1808882048], length 0 13:54:09.263836 IP (tos 0x0, ttl 64, id 43643, offset 0, flags [DF], proto TCP (6), length 52)     lan_host.51155 > remote_host.30022: Flags [F.], cksum 0x904c (correct), seq 0, ack 1, win 115, options [nop,nop,TS val 2398330 ecr 1808805240], length 0 13:54:15.815396 IP (tos 0x0, ttl 64, id 43644, offset 0, flags [DF], proto TCP (6), length 52)     lan_host.51155 > remote_host.30022: Flags [F.], cksum 0x89e6 (correct), seq 0, ack 1, win 115, options [nop,nop,TS val 2399968 ecr 1808805240], length 0 13:54:28.904119 IP (tos 0x0, ttl 64, id 43645, offset 0, flags [DF], proto TCP (6), length 52)     lan_host.51155 > remote_host.30022: Flags [F.], cksum 0x7d1e (correct), seq 0, ack 1, win 115, options [nop,nop,TS val 2403240 ecr 1808805240], length 0 13:54:55.112219 IP (tos 0x0, ttl 64, id 43646, offset 0, flags [DF], proto TCP (6), length 52)     lan_host.51155 > remote_host.30022: Flags [F.], cksum 0x6386 (correct), seq 0, ack 1, win 115, options [nop,nop,TS val 2409792 ecr 1808805240], length 0 13:55:47.465207 IP (tos 0x0, ttl 64, id 43647, offset 0, flags [DF], proto TCP (6), length 52)     lan_host.51155 > remote_host.30022: Flags [F.], cksum 0x3066 (correct), seq 0, ack 1, win 115, options [nop,nop,TS val 2422880 ecr 1808805240], length 0 [/s][/s]

I just read in the cook book that L2TP is not a secure protical and needs to be used in conjuction with Ipsec. So im going to stick with OpenVPN. Thanks for your response.

Hmm, well that seems very odd.  :-
I can't imagine a situation where the box was unable to save the webgui changes correctly that would result in some errors.
I think at that point with unexplained behaviour I would think about reflashing the card.

Anyone else got any ideas?

Steve

Unfortunately your SATA controller and on board Intel NIC are both still on IRQ 20. Hard to know how to get around that. You may have options to move one or other in the BIOS. You could possibly boot from CD, which is PATA connected, and disable SATA. That would prove the IRQ theory at least but seems like a lot of trouble to go to.

I'd have to first suspect that, realatively ancient, Realtek NIC.

Try my test if you can. You can setup pfSense as a client behind your soho router to avoid disruption. Just set only one NIC and use fxp0 for it. With only one NIC pfSense will allow you to connect via that interface (which will still be called WAN).

Steve

Thanks Jim.  I will head out to the datacenter tomorrow and try a different cable.

In the meantime, I chose the LAN interface for the config sync until I can get the failover interface working.

Appreciate your assistance…

Oops! My mistake, not sure how that happened.  :-[

Steve

@Darkriser:

Will post the HP models tomorrow, just to let u know….

The original PC was:
HP Compaq dc7100 SFF

The current PC is:
HP Compaq dc7600 Convertible Minitower

Yes, though I would haver thought those switches might support several types.

Actually reading the user guide it supports port/link aggregation but it doesn't specify if it's LACP compliant or using their own protocol.  :-\ Try it and see.

Steve

hi, thanks for the input. you were right..  LAN has conflict with another gateway! thanks :)

While capture is running, do I need to leave the browser tab open or can I close it can come back later?

Pretty sure it would end when your browser session does. Not real sure. But if you ssh in and run a tcpdump command, like say

tcpdump -n -i <interface>-W /path/to/somefile.pcap</interface>

That will run until you kill it. You can also download that via the web interface (diagnostics->command prompt) or over via scp.  And you can examine the .pcap file at your leisure.

If they are stored, how would I go about locating them and deleting them?

Diagnostics->Command prompt. SSH shell is much easier for this.

Is there a way to run a capture that only records in 20 minute intervals but only keep 5 pcaps at a time??

Sounds like a job for cron and scripts. I wouldn't try and use anything on the gui web interface for that. 20 minutes interval cron jobs running a script that makes sure you only have 5 .pcap files, and then tcpdumps a new one. I don't know of anything analogous to that wireshark command that's a stock utility.

It sounds like you are just worried about storage. pfSense does a have way to integrate remote storage for logs. Not sure if that extends to packet capture. If you can make a firewall rule that matches a filter string and log it to remote storage, then you'd be doing the same thing.

I just noticed the "Count" field. If I set this to something like 250000 would that basically be like retaining only the most recent 250k captures, or does that mean stop logging after 250k is reached?

The latter in my experience.