Well, i feel a tad sheepish, and assish, but it was my reinstall of windows8 that was causing the problem.  I thought of that, but, 1-couldn't think why that would cause a tracert done by pfsense itself and all the other connected systems to go bad, and 2-could see no indicators of windows being set up differently, or anything that I could see that suggested some kind of 'footprint' of windows getting it's grubby fingers into the mix.  I need to talk to timewarner about the erroneous traffic reporting, but such calls tend to make me want to kill myself, but ya gotta do …

Thanks for the suggestions guys, have a good one

Thanks!!!!!

What I've been searching for!

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