@patch said in pfsense on Proxmox - Help with config:

@natharas
An over view of your network architecture would help

Is the Asus DSL-AC68U configured as a modem only (bridge mode) or a router Why is the Asus DSL-AC68U connected to the TP-Link SG2210P rather than directly to the WAN NIC on your Dell PowerEdge T420. Your Proxmox should be managed via your LAN not WAN port as should pfsense

Alternatively your could configure both DELL nic in LAG and use VLANs on your L@ managed switch to separate WAN and LAN but I would not recommend starting with that

Thanks for the reply

It is currently configured as modem only, I do believe it can be bridged though. I've attempted connecting to the WAN NIC on the Poweredge T420 but had no luck getting a WAN IP via DHCP.

@keyser So I just setup a VM running pfSense on my Synology NAS along side my UniFi network.

I'm really glad I spun up an isolated VM this way (with one of my extra public IPs) without having to eff with my production network. I just configured a VLAN-only network on my UDM and assigned it to some switch ports to test with.

Man, I am absolutely loving pfSense so far! What a great product. I might end up having to buy a 6100 after all. Everything just works on the first try (DDNS, PIA, pfBlockerNG, Suricata, and ntopng).

Thanks again for sharing your experiences and opinions.

@sabrielandoj
If you ping from the pfSense GUI using the Ping tool with the default source (WAN IP) all devices on the 192.168.7.x network should response.
If they don't, but do if you ping from other machines in this network, there must be something wrong in the network settings on one involved device.

If you change the source to LAN it's expected that pings won't work, as long as the devices have no route for 192.168.6.124/25 pointing to pfSense. Responses will be sent to the default gateway.

OK, the solution was to install in a local Virtualbox on my computer with a similarly sized HDD. I then shut down the Virtualbox VM before it rebooted into pfSense after install and cloned the disk to the OVH VPS. Works like a charm! Also much faster.

@blcktape That was already in place. This issues was different than the 100% slow down all the time those settings fix.

@viragomann

https://www.youtube.com/watch?v=hdoBQNI_Ab8

this video did not elaborate this issue after the installation of pfsense

Capture.PNG

See the comment by one of the viewers as well, we might have similar question

@laszlo said in Proxmox, pfsense, bridge:

I'm bridged the second 2 interface. VLAN untagged management network the bridge, and the tagged VLANs on the interfaces. (100, 102 the first, 101 the second)

Uhm...
In pf you should have 1 physical interface with your 3 VLANs tagged, making 3 interfaces in pfSense.

Then your ProxMox should have 1 connection to a switch, which has all three VLANs tagged on that port.

Bridges in FreeBSD should be avoided.

@brianmcg
Hi Everyone,
I've fixed it myself. :-) I had to turn OFF "Enable Secure Boot" in VM's Security Settings. pfsense is now running.

@thimplicity OK, I got impatient with all the reboots and started the journey yesterday. I created a new VM according to the official pfSense instructions and set it up as q35 with UEFI. I decided against just rolling back the config and will configure the stuff from scratch. So far the basics that I have configured work without a hitch, but it has only been 10h.

Thanks for the input!

Sure, I'll answer questions as time allows.

I agree with what @Patch said previously though. You need to discover how to do a lot of this for yourself in order to learn from it.

Steve

@srytryagn
Running pfSense virtualized on top of another system naturally adds an additional layer to the whole system, which may offer additional vulnerabilities and possibilities for attacks. These grow up with the number of services you're running on the host.
Hence I'd not recommend to run a production pfSense on a PC which you use for working, playing or any other purposes.

However, if you virtualize pfSense together with other machines on a dedicated hypervisor system I'd not much concerns due to security.
But Windows + Virtualbox is not really well eligible for these purposes in my opinion.

For instance, my home pfSense runs virtualized on top of Linux with KVM aside from a web server to achieve better utilization of my hardware and safe cables, energy and hardware costs.
The host itself is only connected to the LAN side of pfSense, so the firewall secures my whole system. The pfSense WAN is connected to the ISP modem and establishes the internet connection via PPPoE.

Natting the traffic on the ISP router is basically not a security issue as long as the router works reliably.

If pfSense can increase security for the VMs depends on your network design. pfSense, whether bare metal or virtualized, can segregate your (virtualized) network, you can drive this up to connect each VM to a separate network interface if you want, so that no VM can access anything without passing the firewall.

Here is the ARP table of the pfSense.Screen Shot 2022-07-07 at 9.35.06 PM.png

I can't really comment in detail here. I don't use ESXi myself.

Do you still have access to the pfSense WAN after making that change?
What connections are you actually losing?

Obviously access to the management would then be via port forwards or VPN etc so connections there would have to be remade if that was not already in place.

Steve

@deanfourie said in pfSense on HyperV = Massive problems:

Lets take for example my WAN interface. I have the ability to DISABLE IPv4 on this interface.

No, you wouldn't share this with the host to begin with so no need to disable anything.

It will look like this on the host, don't mess with it.

Capture.PNG

@brucie
All software has bugs and security vulnerabilities.
With pfSense running on bare metal the possible locations for bugs are:

Hardware pfsense (FreeBSD retained code, Netgate code) pfsense user customisation / added packages

Note Netgate removes none essential components from FreeBSD to reduce vulnerabilities / minimise the attack surface.

With vitalisation you add

Proxmox ( Debian 11.3 retained code, QEMU 6.2, Proxmox code)

The most exposed of which to external attack is probably the WAN port which is why some pass through at least the WAN NIC.