Nope. I also haven't got an iPhone :)

Hi, And did you added firewall allow rules for your dvr ports? And what is/are your dvr port(s) And if you want to connect default port (80) it might be conflict witrh your pfsense box port. You should change web access port on your dvr device. Regards, SGTR

Very good point! Hmm I will give it a try and see what happens. Sounds a lot more simple anyway.

@jimp: The backtrace seems to indicate a problem in memory or the hdd, hard to say for sure since it just mentioned that it crashed while operating in the swap space code. That's deeper down in FreeBSD than we touch, so it isn't likely to be an OS or pfSense issue, most likely hardware in some way. Thanks for the tip! Will do a hardware diag during off hours. Appreciate the super quick response! -M

I have the same issue but it seems people who are testing it don't happen to experience it.

PERFECT! In the System -> User Manager section, I clicked on edit admin account. In the "Authorized keys" section, clicked "Click to paste an authorized key." I had to re-type in my password, because I kept getting an error that the passwords didn't match.  Once I did that, it worked like a charm. Thanks again!

ok, got it working.  not sure what the deal was, i didnt change anything today. i plugged the cisco router into opt1, just as i did last week, and it worked w/o any issues.  i used the same straight through cable that i had left on site. anyway, just wanted to update the thread. thanks.

Well, it looks like "Have you tried turning it off and on again?" Has succeeded after a 2nd reboot.

Bump. Anyone? Is this in the right forum?

I investigated the STP option in the past when initially setting up a second FW with Carp but it was a disaster. I ended up having to get a second IP range and go fully routed. So is there any other way of me trying to achieve firewalling one IP range across two interfaces with Carp?

someone could make a simple package that includes the man pages and required commands, but we aren't going to put them in the base install, no matter what size CF image.

Hi Walla, The system did not respond to keyboard at all. I checked on the health status (temp/etc) and I could not find anything. We do have traffic shaping enabled and this would be right around the time that our off-site backup sync would normally occur. I disabled our off-site backups last night and the issue did not happen again this morning. Im begenning to think that it could be something to do with the volume of traffic hitting the traffic shaper and killing stuff.

You would definitely get better responses on a squid forum or centos forum.

locking this one since the problem is better defined in the linked CARP thread so this is just a duplicate.

2.1 can do pure NAT mode reflection which gets rid of netcat. That ticket probably just needs to be closed since the pure NAT mode should work fine in every case including UDP. The original mode is retained just in case someone prefers it.

Hmm. May have jumped the gun a little. The issue still seems to occur, albeit less frequently. It now seems quite intermittent in its timings. Any more advice? Tom.

A snapshot of 2.1 didn't help. The weirdest part is the OS never stops responding to ping and the web interface never goes down after I issue the shutdown command. It's like the OS isn't even trying to shutdown.

@Alphaphi: 1. Do you see the 192.168.100.x address in System > Routing in the WANGW (default) line while your ultra-fast connection is established? Which IP do you see there during normal operation? When the modem's WAN connection gies down, Default Gateway and Monitor IP get set to the modem's admin IP (192.168.100.1). When everything works as it should, both entries are set to my ISP's gateway (62.143.x.x). @Alphaphi: 2. What did you do to work around this effect? Is there a way to make pfs not request/receive this unwanted dhcp traffic? I had my ISP fix the cabling (the cable fault was outside the area of my responsibility). ;) As DHCP communication is based un UDP, it should be possible to create a firewall rule which blocks UDP traffic from the moden's management IP address. Source port would be 67, destination port 68, source address the management IP address of the modem (192.168.1.1 or 192.168.100.1 or whatever, depending on the model). I haven't tried this out, but I know of people who accidently blocked their WAN DHCP server, so it should work ;) Of course, all of this assumes that the root cause of your issue is somehow related to the effect described by me. Which I'm actually not totally convinced of. Best regards, Klaus