""Bridge LAN ports to act like a switch".. but will just get a switch." Good choice!

Hi, It's not immediately clear what you are connecting here but the short answer is no. pfSense will block all incoming traffic on an interface by default so unless you add rules to allow traffic between those subnets it will not pass. If we had a diagram of what subnets you're connecting and a description of why we could probably offer more insight. Steve

No. And 2.4 is already using FreeBSD 11.0.

This all makes sense. Thank you.

I had the same issue just now on a new pfsense VM, seems switching back to the stable repo fixed it, so currently development repo is broken?

@Gertjan: Setting up a VPN before even have a WAN access ? I'm impressed. That's not quite what I meant. What I meant was setting up the new interface for the VPN service, CA.cert, tls key, options, the NAT/outbound/firewall on that interface etc. I didn't actually mean to connect to the VPN. D'oh ! @Gertjan: Knowing that pfSense is as easy to setup as DD-WRT (as a firewall / router) - if not easier, I advise you to: Setup the correct LAN, then: 3. 4. 2. Done. Point noted. Thanks.

Great news logbuilder!

Yeah. Just put them behind something else that NATs for them if they need internet access. Otherwise just put them on a blank VLAN or a host-only vswitch. You are going to have to really be careful if you want to access one 192.168.193 network from the "real" 192.168.193 network. And you won't be able to just tell a host on the "real" 192.168.193 network to access something on the test 192.168.193 network using that address. I know of no way that can be done while also maintaining separation between the two.

@stephenw10: That panic is the result of booting the upgraded drive? What happens when you try to boot the memstick install image? What image did you use exactly. Steve It was actually bad USB drive…, i put everything on different usb drive and load it with memstick and restored everything.

Yeah, verifying the sha256 sum of the public key is an important step but so is verifying the sha256 sum  and signature of the actual signed data. My understanding of the chain of trust is that the "fingerprint" ie sha256 sum of the public key used for signing is included in the distribution. That's step 1. Step 2 is using the public key to verify the signature, digests.sig.  That's what the command "openssl rsautl -pubin -inkey digests.pub -verify -in digests.sig -asn1parse" did. The fact that it returned an asn1 encoded sha256 hash tells me the signature was valid. The problem arises with step 3. Step 3 is verifying the asn1 encoded hash matches the sha256 sum of the actual digests file. That's where the mismatch occurs. See this link. https://lists.freebsd.org/pipermail/freebsd-ports/2014-February/089751.html

I have a windows server 2012R2 hyper-v with pfsense, among other things. I suggest you use the following setup: Create two virtual switches. Call one WAN and the other LAN. For the WAN switch, use external network, since it's an external NIC. Do not select allow the management operating system to share this nic. For the LAN switch, use external network, since it's also an external NIC. However, do select allow the management operating system to share this nic, so you can access the hyper-v from within the LAN. When you create the guest for pfsense, create it with two network adapters, one connected to each of the switches. When you install pfsense, you will need to know the MAC addresses of the two adapters so you can select hn0 and hn1, accordingly.

Tried Ctrl+F ? Or you want to search in multiple aliases if a IP exists in any of them with a single search action.?.

You can ping 2.1 from your laptop because that's the interface IP in pfSense so traffic never has to leave the firewall on VLAN 10. That IP would be reachable even if it were on an unplugged physical interface. There is a layer 2 problem between the firewall and the hosts. We would need to see how the interface is configured in pfSense and how the switch is configured to know more. Steve

just an update, after trying many builds I tried yet another hdd (drive 3) and that worked fine…. I can guess that the initial drive might have been dying, the second one worked fine in other device and would accept the install files so pass on that one. anyway its back up and running on 2.3.4-RELEASE (i386)

Thanks for your reply. In the first case once without internet I was able to update it. Change the path of the repository in /usr/local/share/pfSense/pkg/repos/pfSense-repo.conf and download the entire repository from the internet and copy it to a local folder to which I point the pfsense and manage to update it. But it was in an earlier version of PFsense. Now it does not work for me. In the second case in previous versions there was an option in PFsense to be able to change the download path and existed to add a proxy if we were behind one. I can not put myself in front of the proxy because it is very above my company. Thank you I will continue testing until it works

glad you got it solved. for future reference, issue might be the USB. Try using an old 1 or 2GB USB

Ok, I wouldn't anticipate any problems doing that. You can certainly bridge two interfaces and have NAT from a third interface. As described in that thread it would be common to assign the bridge interface and put the WAN on that complete with one of the public IPs. Steve

I would not expect to have to add anything to allow this. By default the LAN interface allows out all traffic from LAN side clients. However if you've added a VPN client you may be policy routing some traffic. That might apply whether or not the VPN is up. I assume this breaks streaming even when you;re not using the VPN? Steve