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.

No, this message is not in the right place. This shows up after saving the interface with new subnet and it's waiting APPLY. But before this APPLY is press DHCP range should be changed or else one locks out.

There isn't, but it's on the to-do list.

You can add a policy route to make sure traffic for your email server always goes via one WAN. Add a new firewall rule on your LAN. Put the rule above your existing rule that allows traffic out so that it catches your mail traffic. Protocol: TCP Source: LANnet Destination: Your mail server IP (or an alias containing a range of IPs) Gateway: WAN1 gateway (this is a an advanced setting). Like you have said most email servers don't have a problem with mulitwan these days. Gmail hotmail etc, no problems. Steve Edit: You have already asked this question twice. Both times I advised you to use a policy route.  ???

I assume it was a cert error with OpenDNS.  Although they say that's how it should work, I've had to drop their service for anything vert-related because it just doesn't work.

I did  and rebooted  things sort of started to work. I had to disable Cp for now. I'm trying to use freeradius2 with mac auth on a lan with 20 clients. It's a small wisp. All the clients have a wireless radio , some have the router in the radio enabled some radios are bridged and they use their own router. Seems I'm having issues with witch device's mac address is actually sent in the packets to the Pfsense box.

I do the same thing, never worried about it too much - its only a few seconds.  But I keep meaning to try this out since this is a few seconds delay as well http://doc.pfsense.org/index.php/Remove_F1_Boot_Prompt Maybe your interested in that as well?

Damn! I looked at your screen shot earlier and failed to spot that.  :-[ Yes, that's certainly your problem. The sandboxed VM cannot possibly respond to any requests from the pfSense machine because it will just send any traffic to the proxy internal interface instead. I see why it is done like that, you can bring up a test VM with the production config. The answer here is to change the proxy internal interface IP. That will mean you have to manually configure the VM gateway as you say but it will resolve the problem. Steve