@marcg said in pfSense firewall: Good for learning if nothing else. Right. Over the years I've seen the occasional post expecting to install it as a program or something like that, so I was just asking. It would be more complex to use as an edge router in a laptop VM. I didn't even see your post, it must have been just as I was saving.

@stephenw10 Okay that's good to hear. I wasn't sure. Thanks.

No need to apologise. This is a useful thread in diagnosing this sort of issue.

pfsense-redactor 1.1.2 released - much wider secret coverage since 1.0.x Open-source tool for stripping secrets out of config.xml before you share it with support, a consultant, a forum or an AI tool. Python, standard library only, no dependencies. Quite a lot has changed since the last update in this thread. The main one is coverage: secret detection now matches the element names pfSense and its packages actually write, rather than the ones you would guess. SNMP: rocommunity, rwcommunity Wireless: passphrase (WPA/WPA2 PSK) VPN: auth_pass, presharedkey (WireGuard), ipsecpsk, eap_password Auth: radiussecret, authorizedkeys Packages: accountkey (ACME), dns_cf_token and maxmind_key (pfBlockerNG), influx_token (Telegraf), tlspskvalue (Zabbix), access_key and secret_access_key (S3), userkey (Pushover), ha_certificates and ssloffloadcert (HAProxy) Suffixed spellings are handled too, so password2 and passwordagain go the same way as password. Beyond element names: URLs are taken apart properly. Credentials in query strings and in user:pass@host are redacted, not just the hostname Slack, Discord, Telegram and Teams webhook tokens go in default mode. The URL is the entire credential, so anyone holding it can post as that integration Free-text blocks such as custom_options are scanned for inline credentials, which is where OpenVPN auth-user-pass and askpass usually live PEM and base64 key material is detected by content, in any element --redact-descriptions covers free-text elements and attributes, for the DHCP static-map descriptions that quietly collect people's names It also tries hard not to over-redact. Network topology survives, so the config is still readable for troubleshooting, and pfBlockerNG feed URLs like emerging-block.rules are left intact rather than mangled into example.com. Whatever it decides to keep, it tells you about, with the element path. For automation, --fail-on-warn turns it into a CI gate: non-zero exit if anything high-entropy was retained, --dry-run included, so you can check a config without writing one. There is a benchmark in the repo. 46 planted secrets in a published corpus, 42 caught with --aggressive and 43 adding --redact-descriptions, with the misses listed and explained rather than hidden. The corpus and the scoring both ship, so you can re-run it yourself instead of taking the number on trust. Default mode catches fewer and the docs say how many. If you are on 1.0.x, the coverage difference is large and worth the upgrade. https://pypi.org/project/pfsense-redactor/ https://github.com/grounzero/pfsense-redactor pip install pfsense-redactor Python 3.9+. Redacted output is for sharing only. Never import it back into pfSense.

@zikou Please follow this: https://docs.netgate.com/pfsense/en/latest/recipes/virtualize-proxmox-ve.html

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.

@JonathanLee Yeah maybe a virtual router. I'll consider that, Thanks for the advice.

@Stp well if you can ping 8.8.8.8 then internet is working.. Your problem is prob dns related.

@Enso_ I was talking about the firewall on the destination machine. To investigate the issue, sniff the traffic with packet capture on pfSense on the LAN interface and see if you get both, request and response packets.

@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. Similar to this: https://forum.openwrt.org/t/sophos-xgs107-and-no-network-interfaces-unknown-network-controller/168989 Depending on the switch IC used it might have a serial interface that's accessible. If you're lucky!

@aes4096 said in ACME IP address or domain: 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. https://www.youtube.com/watch?v=2oe7rTMFmqc https://www.youtube.com/watch?v=7_gLPyipFkk

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.

@optimusprime 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. @optimusprime said in pfSense Exam & Certification: At official netgate site 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.