Alright, it is now working 8) Although I'm actually not sure which step fixed it. 1. I read some more about configuring, and watched some really good guides to getting through the install, and getting to the webgui. 2. I reinstalled pfsense, just to be sure i didn't mess something up from first round. 3. After  the installation was complet, I was again greeted by no Wan or Lan address. I had left both lan and wan cable in. 4. Assigned interfaces. Assigned em0 to wan, em1 to lan. Nothing 5. Assigned interfaces again. This time em1 to wan, and em0 to lan. Nothing. 6. Went to our ISP device. Which looks like a router. Cable from the wall, four Ethernet ports, wireless etc. But I don't see how it can be doing router duty now, since my freenas has been assigned a 86.xx.xx.x DHCP4 ip address, and my frinds asus router has a 85.xx.xx.x address Unplugged the cable to my pfsense box, aswell the cable to my friends asus router. Then plugged my pfsense box into the ethernet port the asus had. Nothing. 7. I unplugged both wan and lan cables from my pfsense box, and the assigned interfaces again, this time with auto. It detected uplink on both. But nothing. 8. Went back out and put the asus routers cable back in the ethernet port it had in the beginning. And reconnected my pfsense to another ethernet port. 9. Then when I came back, it had obtained it's (public?) 86.xx.xx.x address, kicked out a lan address. And I was able to go to webgui. Yay :) I'm very happy that it works now. But I would also like to know why it didn't work in the first place. Was unplugging and re plugging the two routers simultaneously the trick? Or that, and a reassignment of interfaces? Also thanks for the help and input :)

If that is the case, why are LRO and TSO even displayed as options that could be flipped? They (the developers) don´t know what hardware will be in the game including the NICs and there fore it might be better to turn it off by default but able to enable it if needed matching to the right hardware, case or situations. Do not uncheck this option unless directed to do so by a support representative That only means that it would help perhaps in some rarely cases and this should be only set or turned around if a supporter is telling a customer to do it. Since I'm on an SG-4860 with its Intel NICs, I assumed I could turn all those "Disable Hardware" options off and did so.  Only now that I'm reading the book do I see I was wrong. Then you should not do anything like this, because this SG units from the pfSense shop came with a pre-tuned pfSense system and they (the developers) know this hardware to 100% and what is going on with its tunings.

@doktornotor: What alert/notification/error? If I'm trying to set that "private key" which I shouldn't be able, I would expect an error/alert message. not only I don't get that a new default webConfigurator certificate is being generated and assigned to be used - why?

Thanks Fabio72…While I get this going I have snort running on my VPN and wan...I want to get to PfBlocker in the long term but today I am still using OpenDNS. While not private I think I am getting some extra security. I need to work out how to get PfBlocker working on my LAN and multiple VLANs. Thanks again for he help...

Perhaps there might be also professional Support that might be a chance to solve this out at a glance? https://www.netgate.com/support/ or mail to support@netgate.com If to high in price you may also be happy with a SG unit from the pfSense store that comes pre-installed with pfSense.

Hey, you can look at this thread, it does support DMVPN. https://forum.pfsense.org/index.php?topic=103242.0

Also my pfsense runs on vmware workstation and I have a sneaking suspicion that could be interfering? Internet –- pfSense --- Switch --- Merlin router in WALN AP mode That would be my set up to learn about VLANs and with two SSIDs (WLAN private and guests) you might be needing tagged VLANs and if you set up only one SSID (private WLAN) you may only need a untagged VLAN. Would be nearly comming to real situations also at home. Forget the dump Switch please, for ~$25 you may get a small Netgear GS105E that will be non configured working or acting as a dump Switch and it supports VLANs if you configure it over the webgui.

Upon further testing I have ascertained that the MTU for the network as a whole, is set within the VPN. I tested with these settings: host: 1500 openvpn: 1500 router: 1492 Pings at 1473 were fragmented and pings at 1472 passed. When I set the openvpn client back to 1492, pings at 1465 fragmented and pings at 1464 passed. So it appears that the router MTU setting, has no effect on an encrypted tunnel. As per the description "maximum transmission unit", I can only assume that if I set my host to limit at 1492 it will formulate packets of 1464 bytes and append a 28 bit header to make up the 1492. Someone please correct me if I'm wrong. For now this is solved.

Some quick comments. You've got a fixed IP which is really not needed - many DNS providers today do dynamic updates - but is handy to have. You will naturally have a DMZ since you will have port 25 world wide open, you really cannot run a MX without it. You mention you have an external VPS, I assume it's Linux. I would install postfix on that VPS and use it as backup MX, you probably want to queue your own mail when you have maintenance windows and miss receiving or if you're on a weekation and the power drops and the server don't come back up. SMTP servers usually have retry algos and keep trying sending for up to some 96 hrs before returning errors but I think it's nice to have backup MX anyway - it makes sure the sender don't get any kind of warning or dealy info sent back (this may or may not be good that's up to you I guess). I would also use that VPS for outbound SMTP (to the world), since it's most likely non-residential and non-dynamic IP that will probably work fine. If you want you could set up VPN site-site to that VPS and tunnel outbound mail plain from your local mail systems in that tunnel and also receive rsyslogs from the server over the tunnel to a central syslog server. The mail system that the users use can be many things and it all depends on how many servers you want to have in the mail design - myself I have 3 locally in my personal network handling different aspects of the mail feed. I would strongly suggest you look into Zimbra as your main mail engine, webmail and collaboration system alike. Quite possibly the best I've ever seen and I have used a number of mal servers/system during the years. Other options may be Zarafa and possibly Axigen. Remote access to mail can be over OpenVPN (demand everyone including phone to first setup tunnel before accessing services) or a mix, perhaps you'd like to have https, pop and imap open to give users flexibility. I'd recommend using Snort to increase the likelyhood that you notice if there's a lot of malicious activity going on. I'd also recommend using some blocklists (you can do that in FW-rules instead of Snort) like ET IP lists, CINSscore and Talos. Be wary of DNS block lists (real time block lists) in the SMTP system, many give you issues of false positives, the only I use on and off today are Spamhaus and sometimes Spamcop. Rejecting SPF failures may also give you some issues but is a nice thought I think, unfortunately there's a lot of admin that do not keep accurate SPF records. Just a few various thoughts on the subjects. Regards,

The General Setup DNS servers are for the firewall to resolve names. If you do not have any DNS servers defined in the DHCP server it will serve the interface address if DNS resolver or DNS forwarder are configured. If neither are configured it will serve the DNS servers defined in General Setup. This is not a guessing game. You should be able to look at the DNS servers that were given to the clients and whether they can or cannot resolve names. If they cannot you would investigate why they cannot. Leave blank to use the system default DNS servers: this interface's IP if DNS Forwarder or Resolver is enabled, otherwise the servers configured on the System / General Setup page.

Tried working on this issue some more, but haven't yet found a way to improve recovery time after the ISP connection comes back up. I'm not sure now that this has to do with having two gateways set up. Right now I have gateway monitoring disabled on the IP that points to the SG300 switch. I also had set the WAN interface (igb0) to reject leases from the modem's IP address of 192.168.100.1. Neither adjustment seemed to change the time to recover after the last two ISP outages. I still have to wait for an hour or more after the modem indicated link recovery until pfSense was able to pass traffic to it again. During the outage prior to that using the same pfSense config, after the modem indicates link recovery, removing/reconnecting the WAN network cable restored connectivity immediately. No unplug cycle on the switch-facing links was necessary. I'm guessing the extended delay time if I don't intervene after an ISP outage is the DHCP lease renewal interval counting down to a certain percentage, where pfSense then recovers connectivity on its own. What I get from logs during these outages is: Apr 20 07:13:17 dpinger WAN_DHCP 184.88.32.1: sendto error: 64 Apr 20 07:13:18 dpinger WAN_DHCP 184.88.32.1: sendto error: 64 Apr 20 07:13:18 dpinger WAN_DHCP 184.88.32.1: sendto error: 64 Apr 20 07:13:19 dpinger WAN_DHCP 184.88.32.1: sendto error: 64 Apr 20 07:13:19 dpinger WAN_DHCP 184.88.32.1: sendto error: 64 Apr 20 07:13:20 dpinger WAN_DHCP 184.88.32.1: sendto error: 64 Apr 20 07:13:20 dpinger WAN_DHCP 184.88.32.1: sendto error: 64 Apr 20 07:13:21 dpinger WAN_DHCP 184.88.32.1: sendto error: 64 Apr 20 07:13:21 dpinger WAN_DHCP 184.88.32.1: sendto error: 64 Apr 20 07:13:22 dpinger WAN_DHCP 184.88.32.1: sendto error: 64 Apr 20 07:13:22 dpinger WAN_DHCP 184.88.32.1: sendto error: 64 Apr 20 07:13:23 dpinger WAN_DHCP 184.88.32.1: sendto error: 64 Apr 20 07:13:23 dpinger WAN_DHCP 184.88.32.1: sendto error: 64 Apr 20 07:13:24 dpinger WAN_DHCP 184.88.32.1: sendto error: 64 Apr 20 07:13:24 dpinger WAN_DHCP 184.88.32.1: sendto error: 64 Apr 20 07:13:25 dpinger WAN_DHCP 184.88.32.1: sendto error: 64 Apr 20 07:13:25 dpinger WAN_DHCP 184.88.32.1: sendto error: 64 Apr 20 07:13:26 dpinger WAN_DHCP 184.88.32.1: sendto error: 64 Apr 20 07:13:26 dpinger WAN_DHCP 184.88.32.1: sendto error: 64 Apr 20 07:13:27 dpinger WAN_DHCP 184.88.32.1: sendto error: 64 Apr 20 07:13:27 dpinger WAN_DHCP 184.88.32.1: sendto error: 64 Apr 20 07:13:28 dpinger WAN_DHCP 184.88.32.1: sendto error: 64 Apr 20 07:13:28 dpinger WAN_DHCP 184.88.32.1: sendto error: 64 Apr 20 07:13:29 dpinger WAN_DHCP 184.88.32.1: sendto error: 64 Apr 20 07:13:29 dpinger WAN_DHCP 184.88.32.1: sendto error: 64 Apr 20 07:13:30 dpinger WAN_DHCP 184.88.32.1: sendto error: 64 Apr 20 07:13:30 dpinger WAN_DHCP 184.88.32.1: sendto error: 64 Apr 20 07:13:31 dpinger WAN_DHCP 184.88.32.1: sendto error: 64 Apr 20 07:13:31 dpinger WAN_DHCP 184.88.32.1: sendto error: 64 Apr 20 07:13:32 dpinger WAN_DHCP 184.88.32.1: sendto error: 65 Apr 20 07:13:32 dpinger WAN_DHCP 184.88.32.1: sendto error: 65 Apr 20 07:13:33 dpinger WAN_DHCP 184.88.32.1: sendto error: 65 Apr 20 07:13:33 dpinger WAN_DHCP 184.88.32.1: sendto error: 65 Apr 20 07:13:34 dpinger WAN_DHCP 184.88.32.1: sendto error: 65 Apr 20 07:13:34 dpinger WAN_DHCP 184.88.32.1: sendto error: 65 Apr 20 07:13:35 dpinger WAN_DHCP 184.88.32.1: sendto error: 65 Apr 20 07:13:35 dpinger WAN_DHCP 184.88.32.1: sendto error: 65 Apr 20 07:13:36 dpinger WAN_DHCP 184.88.32.1: sendto error: 65 Apr 20 07:13:36 dpinger WAN_DHCP 184.88.32.1: sendto error: 65 Apr 20 07:13:37 dpinger WAN_DHCP 184.88.32.1: sendto error: 65 Apr 20 07:13:37 dpinger WAN_DHCP 184.88.32.1: sendto error: 65 Apr 20 07:13:38 dpinger WAN_DHCP 184.88.32.1: sendto error: 65 Apr 20 07:13:38 dpinger WAN_DHCP 184.88.32.1: sendto error: 65 Apr 20 07:13:39 dpinger WAN_DHCP 184.88.32.1: sendto error: 65 Apr 20 07:13:39 dpinger WAN_DHCP 184.88.32.1: sendto error: 65 Apr 20 07:13:40 dpinger WAN_DHCP 184.88.32.1: sendto error: 65 Apr 20 07:13:40 dpinger WAN_DHCP 184.88.32.1: sendto error: 65 Apr 20 07:13:41 dpinger WAN_DHCP 184.88.32.1: sendto error: 65 Apr 20 07:13:43 dpinger send_interval 500ms loss_interval 2000ms time_period 60000ms report_interval 0ms data_len 0 alert_interval 1000ms latency_alarm 500ms loss_alarm 20% dest_addr 184.88.32.1 bind_addr 184.88.44.86 identifier "WAN_DHCP " Assuming dpinger should be the agent triggering recovery actions, if it doesn't know how to handle this kind of outage on its own, I might end up just implementing a less-than-ideal cron script to check a few IPs periodically and cycle the interface if none reply. Not a good solution, but its all I can think to do at the moment.

@stephenw10: It's logging and blocking that traffic because it's matching the antispoof rule. Looks like it's coming into the VLAN interface from a IP that is in the LAN subnet. I assume the LAN in 172.16.0.4? That's the expected behaviour. https://www.openbsd.org/faq/pf/filter.html#antispoof Steve Thanks for the reply…  I didn't realize I had the IP address reconfigured.

What is the upload bandwidth at the server end though? That is the limiting figure here. What speed are clients seeing when connected? Steve

It is too much  for my mind… Yes, now I know you are both right. But now, when I'm using peek and splice all mode with MITM and I can see every certificate verificated by.. i.e. Verisign, Symante, Oracle.. now my network settings are right - am I right or am I wrong? EDIT: I found that thread https://forum.pfsense.org/index.php?topic=123461.0, there is more explanation about my doubts. Thank you once more.

Many modems can be made to present themselves differently in various modes. It might be possible to switch that device to appear as USB serial. More Googling required.  ;) Steve

Shortened the dhcp lease per suggestion and made the changes. Everything went smoothly. Many thanks for all the help.