Ok, I'll have to wait until tonight so I can grab the full log.
(It was in the middle of occuring when I tried to login to verify the namecheap dns settings for the other topic >.< )

I think more information is required. Is the Netgear in the same subnet as the LAN on pfsense?
Yes, you can setup an IP Alias with the same IP as the netgear. If it is on a separate subnet, then you will only need to create FW rules to allow it and NAT rules so that traffic going out to the WAN is natted. Traffic between the 2 subnets should be automatic.
Personally, I would force default GW change, but this could be done for a slower transition. Those that are DHCP should transition over to the LAN IP by default.

Each network (LAN and OPT1) need to be a completely different IP subnet - e.g. keep LAN as 172.20.2.0/24 (pfSense LAN IP 172.20.2.83) and make OPT1 172.20.3.0/24 (pfSense OPT1 IP 172.20.3.83). Otherwise the routing will get very confused about where packets need to be delivered. An "allow all" rule is automatically put on LAN by default. Other interfaces have all incoming connect requests blocked. So yes, you have to add pass rules on other interfaces to let any traffic happen (e.g. as you say, put an "allow all" rule on OPT1, just like LAN).

I toke the machine to my network and no crash at all.

I replace the box with same hardware profile in another  environment and 2.0.3 version, still crashing. Then return to 2.0.1 version, but still crashing. Very strange problem.

I send crash reports every day, hoping someone helps.

May  9 14:14:52 sec kernel: Fatal trap 12: page fault while in kernel mode May  9 14:14:52 sec kernel: cpuid = 1; apic id = 01 May  9 14:14:52 sec kernel: fault virtual address      = 0x10 May  9 14:14:52 sec kernel: fault code          = supervisor read data, page not present May  9 14:14:52 sec kernel: instruction pointer = 0x20:0xffffffff807cad25 May  9 14:14:52 sec kernel: stack pointer              = 0x28:0xffffff803bca43a0 May  9 14:14:52 sec kernel: frame pointer              = 0x28:0xffffff803bca43f0 May  9 14:14:52 sec kernel: code segment                = base 0x0, limit 0xfffff, type 0x1b May  9 14:14:52 sec kernel: = DPL 0, pres 1, long 1, def32 0, gran 1 May  9 14:14:52 sec kernel: processor eflags    = interrupt enabled, resume, IOPL = 0 May  9 14:14:52 sec kernel: current process            = 22984 (openvpn) May  9 18:03:32 sec kernel: Fatal trap 12: page fault while in kernel mode May  9 18:03:32 sec kernel: cpuid = 0; apic id = 00 May  9 18:03:32 sec kernel: fault virtual address      = 0x21 May  9 18:03:32 sec kernel: fault code          = supervisor read data, page not present May  9 18:03:32 sec kernel: instruction pointer = 0x20:0xffffffff807cad1b May  9 18:03:32 sec kernel: stack pointer              = 0x28:0xffffff80395ab4b0 May  9 18:03:32 sec kernel: frame pointer              = 0x28:0xffffff80395ab500 May  9 18:03:32 sec kernel: code segment                = base 0x0, limit 0xfffff, type 0x1b May  9 18:03:32 sec kernel: = DPL 0, pres 1, long 1, def32 0, gran 1 May  9 18:03:32 sec kernel: processor eflags    = interrupt enabled, resume, IOPL = 0 May  9 18:03:32 sec kernel: current process            = 12 (irq260: em2:rx 0)

@stephenw10:

By default filtering is on the bridge member interfaces and not the bridge interface itself. If you are hoping to the use the interfaces like a switch, as you would on a soho router, you probably want one set of firewall rules to apply to all the bridged interfaces. Hence the system tunable change. If you don't do that then you need to add rules to each interface in the bridge.

It deppends how you are using the bridge. You can also have filtering both places if you want to.

Steve

Ok, yes, then I would want to make that change.
Sounds good.  Thanks for the explanation.

First thing you are going to need to do is figure out how many IPs you are going to need per VLAN. Once you do that then you will create the VLANs on your Pfsense router and give them IPs and setup your rules. Then you will create the VLANs on your switches. I would think about how many users you have today and how many you think you might have tomorrow. Then make a network diagram and post it here that way people can help you better.

@Reiner030:

Tim means switches like an D-Link DGS-1008D which we use as standard table switch for other places…
So every user gets his untagged VLAN but our telephones get their VLAN tagged, too.

Actually, the switch I was having problems with is a Dell PowerConnect 5224.  It's a layer 2/3 switch and for some reason I could not delete the untagged VLAN and on reboots all my settings are lost.  Rather than spend the time trying to figure it out (again, "free" switch), I decided to add another switch and physically segment.

Lazy, I know…. :)

That's fine - I have been wanting this to work optimally for my systems, I had been on 4 weeks leave away from easy access to test systems (withdrawal symptoms:) and it was a good opportunity to have a proper look at it.

ahh perfect. thank you kindly!

Good to hear.  :)
I only asked because other users have reportedly done that and ended up misinterpreting the instructions etc.

Steve

It's not straight forward but people have done it. Probably the easiest way to do this is to run a syslog server locally. This means the pfSense logging code remains standard. I believe someone created a package to do this with syslog-ng.

Steve

Edit: Yes, it's here but only available for 2.1 for now.

You can either setup one instance as a transparent firewall, in which case it will have the same subnet on both sides remving the issue. Or have the inner box setup as a router only which is what you were trying to do before. However if you do that you will need to add a route or gateway to the outer instance so that it knows where to send traffic bound for the inner LAN.

It really would be much better to have a single instance of pfSense here.  :)

Steve

The reason you should not use VLAN1 is that the switch uses it internally even if you have no VLANs defined and are using it as an unmanaged switch. You can get odd behaviour if you're not aware of what you're doing. The webgui is on VLAN1 internally in the switch. Usually all traffic with VLAN1 is untagged at every port such that you never see it outside the switch but you can allow it to exit as tagged and that way you can connect to the webgui over tagged traffic.  ;)

You are only doing this because it's not recommended to have tagged and untagged traffic on the same pfSense interface. The reason for that is that some combinations of hardware and driver cannot handle that and end up discarding one of the other. However most people never see this problem so you are probably fine just adding the em1 as an interface to access the switch gui. Just be aware that it may cause a problem.

Alternatively there is often an option to add the webgui to other VLANs so you could just add it to your existing VLAN.

Steve

@stephenw10:

@rakeshvijayan:

my thought may wrong is  sticky sessions means by static ip?

Nope. Sticky connections refers to a setting in System: Advanced: Misc (see attached pic). It is supposed to set the load balancer to use the same WAN for outgoing connections to the same server.

Hmm, re-reading this now it looks like it could be incoming load balancing. That would explain why it seems to have no effect.  ::)

Steve

Well, sticky connections should do as described in the context. As far as I am concern, it did not do what it promised. So I would say either it's a bug or incomplete implementation.

The Mod_evasive per-ip connection to the captive portal issue should be fixed in 2.0.3, which should keep the Captive portal from causing OOM events.  I've upgraded several sites and the memory usage does seem to be lower now.
Josh

Problem solved.

Our ISP changed our IP number a few weeks back during the firewall setup, and the FTP she connects to filter off any non verifyed IPs, and since they didnt have our new IP it was just rejected. Sorry to have taken your time with this.

Kenneth

If you are looking to get the most of your SSH service, read the SSH book by Michael Lucas:

https://www.michaelwlucas.com/nonfiction/ssh-mastery

I am not affiliated with Michael in any way other than having a shelf load of his books.

Ah, I did not realise that. Public iperf servers. Thanks!  :)

Steve

@NOYB:

I did try it.  And it changed MAC for both physical (parent) and the VLAN.  That's reason for the question.

Can you try on a different type of NIC?

@NOYB:

Was expecting that spoofing the MAC on the VLAN interface would enable promiscuous mode and only use the spoofed MAC for the VLAN.  NIC is Broadcom 440x 10/100 (bfe0).

Some NICs don't need to enable promiscuous mode to see frames directed to a "non-standard" MAC address. I think (but its a long time since a looked at this) one way that was done was for the NIC to have a number of programmable MAC address hash registers and a receive frame was accepted if the hash of the destination MAC address matched a value in one of the MAC address hash registers. It was then up to software to determine if there was an exact match between destination MAC address in the frame and "acceptable" MAC addresses.

Update - not a fix to the actual problem, but a workaround:

installed the package "Shellcmd". renamed the script without the ".sh" extension. added this into "Shellcmd: settings" : /usr/local/etc/rc.d/send_gmail_after_startup

Now it only runs once as required.

same goes for any other custom scripts needed to run once at startup.

Hope that helps anyone else experiencing the same problem.