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

I would be suprised to see the Realtek nics limiting to this extent. I have seen very low quality nics limit connection speed to, say, 80Mbps where an Intel card will get 95Mbps+.
To rule this out use your fxp nic as WAN and test the download directly to the pfSense box as you did earlier.

Steve

I'd expect that if you connect to a website for the first time. Further connections (within 5 minutes) to the same website should be faster. If this is the behaviour you observe, then the three DNS forwarders (in the three routers in sequence) might cause the delay.

I am assuming you have (or will have) some way of determining from the client MAC address which DHCP clients in Norway should go through Amsterdam.

I am assuming (since I won't have access to my own pfSense boxes until next week so I can't currently check) that the recently introduced DHCP Pools feature will allow clients to be assigned different gateways based on their MAC addresses and this could be used in the Norway DHCP server to direct clients to the appropriate gateway. See the Sticky note in the "2.1 Snapshot" forum for more information about DHCP server pools. This will only work on all clients if the gateway is on the same subnet as the client. If that is not the case, then I think you can add firewall rules so traffic from a particular client get redirected to a gateway out a particular interface. This feature will be easier to manage if the client IP addresses fit neatly into a subnet (e.g. a /27 subnet of the LAN subnet).

I suspect you won't, in the long term, want clients' DHCP server to be at a remote site. (You probably won't want DHCP to be dependent on a WAN link.)

The external modem is also easier to swap. They don't actually require a lightning strike to get fried, so I prefer to always keep a spare modem on the shelf.

I can even explain a "dumb user" how to swap modems if the internet failed after "something started to smell funny".

I would use virtual interfaces and let hyper-v handle VLAN. Just assign once VLAN to a different virtual switch and put an interface in there for pfsense.
I would imagine you could do it the way you are describing, but I just don't know.

What version is that on?

The CPU being taken by "system" implies that it's being used by pf for packet processing or similar, or in some cases, the GUI.

If this is on 2.0.2, move to 2.0.3 and it should be better: http://forum.pfsense.org/index.php/topic,58203.0.html

Glad I could help.

you are now using your wireless AP as a switch instead of a router. That puts everybody one the 192.168.1.0/24 subnet and gets rid of the 192.168.0.0/24 subnet.