If you're asking can you run pfSense as a VM in proxmox then the answer is yes. But there are some caveats! It's a more complex setup to be sure the traffic is all passing through the VM. If you have to reboot proxmox you lose your router/firewall. There are lots of users doing exactly that though.
@stephenw10 thanks for responding -- yup pfSense update solved this particular issue. Now I'm running into TLS/ cert issues on my dockerized graylog setup, which is probably outside the scope of this forum.
Would be nice to have a standard way to securely manage logs in Pfsense -- one that does not encourage people to send logs in the clear.
I know you can just run a local server and have some security with Rules, but would suggest to have a more formal secure integration with Graylog given how popular it seems to be with people here. Also for people that want to monitor more than one network with one Graylog instance
Ah, OK. Yeah that's not even a known PCI ID. I don't believe there is a driver for it. Certainly not in FreeBSD/pfSense.
But, perhaps more importantly, there is only one Ethernet device shown. That implies the ports there are connected via a switch and that introduces a lot more issues.
I can use the DNS method or purchase a Wildcard certificate with subdomain protection, which is more expensive.
If you can use a DNS Method you can ask a wildcard certificate.
Letsencrypt will still be free of use.
If you own( = rent) a domain name, you control the domain. You are the only one being able to create sub domains.
I can proof that : try creating aes4096.microsoft.com : good luck ^^
@Ratfink Connecting two sites with Wireguard VPN is absolutely doable, and you don't even need fixed IP's for it to work.
When you say you have 5 fixed IP's from your ISP, I'm kind of assuming you have your office at your house? Meaning they are both connected to the same fibre? Otherwise, if they are at very different locations, is it still the same ISP?
In terms of getting the IP's on the respective pfsense machines, I assume you know how or have instructions from the ISP to do this. Might be MAC based if DHCP for example...
Anyway, running pfsense on repurposed HW is very common and can be done "barebone" or virtualized. So you shouldn't have any problems getting to to work on your rack servers, hopefully.
So step one is of course getting both machines up and running. And since they will be for different sites and connected via VPN you must make sure to use different LAN subnets on them. Like 192.168.1.0/24 on one and 192.168.2.0/24 on the other.
Once you have them up and running you can follow a guide like one of these to set up wireguard.
Even though you have fixed IP's it might be a good idea to get two domains, unless you already have that.
I would concur using it as explicit proxy where your devices actual gateway points to pfsense vs the proxy should remove such issues what what your seeing with that 22 traffic you listed.
Other option with putting such devices that are really internal to your network on their own transit network can eliminate asymmetrical flow issues.
@kstlan02
First off, it's not wise to use public IP ranges in the local network, even for docker.
Then I'm wondering, why don't you run the OpenVPN server on pfSense.
Do I have to do the port forwarding from the WAN to the LAN or do I have to do it from the WAN to the Docker container that is running OpenVPN?
"LAN address" is the wrong destination here for sure. This is an IP assigned to pfSense itself. Hence forwarding to it, is not that, what you want.
The question is then, how can pfSense reach the container?
I'd expect, that the container gets its traffic forwarded inside the VM. But don't know, how you did configure it.
So you have to forward the OpenVPN traffic either to the VM address or to the container IP. In the latter case, you would need to add a static route for it on pfSense of course.
@danwize@viragomann
I've got it working now. I changed to just use one front end and added my acl for cloud back. I removed my attempts to set the header and changed my could back end to point to 10.10.0.2:443 after I had changed it to 10.10.0.2:10223 for testing. After I did that, and after saving and applying the changes several times, cloud.mydomain.com was still resolving to 10223. I even tested in igognito windows and restarted the ha proxy service from the pfsense ui and it kept resolving to 10223.
I finally got it routing to 443 after editing the front end settings for cloud to use a different backend, saved those changes, and then changed it back to my cloud.mydomain.com backed and saved again. Possibly my problem from the beginning was the fact that the settings didn't take initially.
pfSense as a software resolution, or boxed into devices like this are not to be compared with solutions from (example) Cisco solutions. Or Microsoft for that matter.
If you look for 'certificates' or 'exams' then you probably won't find what you're looking for.
Look at their other official site.
And while you have Youtube open, tens of thousands of pretty good video's are available from other channels that tell you everything you need to know, and more, as the subject is just huge.
edit : btw : I'm saying all this as this is what I think. I'm didn't 'look'. Maybe it actual exist, but not in my physical neighborhood, and I'm not planning a trip to the US so I can learn the official way how to analyze a NAT rule 😊
It's seeing the 2.5 version. You should normally see that as an available upgrade on the dashboard. If that has been disabled you would need to visit System > Updates.
But from such an old version you should consider installing 2.7.2 clean and restoring your config.
@miracuru
As was mentioned by @viragomann the "Default deny rule IPv(4|6)" logs are normal. Actually they show that pfSense is doing its basic job, which is (by default) blocking all incoming connections to WAN.
You could implement a firewall rule on the WAN interface which does the same thing, but doesn't log the blocks. Enable that rule when you don't want pfSense to record all the WAN blocks in the logs. If you want to start logging the WAN blocks, just disable your rule and the defaults will kick in again.
Also, it may be possible to directly connect the enpf4s0 and enpf7s0 interfaces to pfSense via PCI-Passthrough. This will depend on hardware compatibility, but could be worth looking into; just food for thought.
I was hell if my ISP rollout the OFDMA to the upstream some years ago. And your problem looks similar.
Idle was nice, but if you use the bandwidth, the error rat grows and grows and with it the retransmission and the latency explode.
It takes month and 2-3 construction sites to get a nice stable connection back.
Have a look into it fist.
@dieggocampos Bom dia, descobriu a solução? Eu tenho tido milhões de problemas com skype por exemplo. Estou desconfiado que é a versão do pfsense e estou testando no momento na versão 2.7.0. Até tentei dar uma olhada no e2guardian mas parece que nao faz mais parte da comunidade do PFsense.
