I did it and aswered a couple of questions I had so I'm leaving it here. yes backup/restoring config.xml backups CA and all certificates, noticeably tho if you use the passwd command from shell at anytime be weary the user password you just changed will be reverted back to the one in config.xml at every reboot, you need to change a user password from the webgui to make it stick yes it is obviously possible to restore a confix.xml just after the install process before reboot, the installer asks you at the end if you want a shell before rebooting and you should say yes, then dhclient your network device (I'm using a vps with only one network device vtnet0) and then use fetch/scp to get the config.xml on the box, put it into /cf/conf/confix.xml and reboot, that's basically it. Noticeably the fetch available in this environment cannot open https links without installing root certificates, which I didn't wanted to do because I don't know if it's a security risk (I believe so), so I opted to scp the file from another server I have, scp did not add the ssh key and would fail miserably, you need to ssh into the box to add the key to your know hosts (or add it manually) and then you can scp files from it. So I've created the basic setup (one WAN device on vtnet0 with DHCP and one LAN device on ovpns0) on a VM on my laptop, issued all the certificates and set-up the main admin user and created a firewall rule to allow the OpenVPN port (UDP 1194) from WAN Net to This Firewall, got the ovpn config file from the box and then I exported the config.xml. that's the config.xml I restored to the box just after install having access to it via VNC. device name and assignation during first boot, which was my main question here. the device name is gonna be checked against what's in the config.xml BEFORE starting OpenVPN and creating ovpns device, that introduces a complication here if the device name do not coincide. if the WAN network device name is the same (vtnet0, em0, etc.) in your VM/config.xml file and on your VPS it's all good, the box just starts without complaining, OpenVPN starts it's ovpns device assigned on LAN and you can connect to it just by changing the server IP address on you ovpn file and you got the GUI on the vpn address and at no time the default login has been exposed to the internet. if the device name is not the same it's a bit tricky, because during boot up it's gonna ask you to assign devices BEFORE the Openvpn device (ovpns0) has been started, so you can reassign your WAN but you're gonna loose your assigned LAN because of this. you can obviously fix this via shell (probably haven't looked into it, I'm just learning my way around pfsense) but the easiest way is to just use the same device name in your VM as you're gonna find on your VPS, in my case on my VPS the device name is vtnet0 and you can get that same device on virtualbox using the paravirt driver for your virtual NIC. I believe you can also just change the device name in the config.xml file but I haven't tried it. that's all folks, I hope this can help somebody in need of understanding how to do this. Building a VPN aggregator this way on pfsense gives yo, bandwidth control for each VPN, firewall, IDS, etc.

Missed that page in my searches, thank you. Will give that a shot this weekend.

@lewis said in Allow LAN to LAN, not routing: I said many times, I've never done this before, it's a live network that I cannot mess up. My point exactly.

It isn't possible for you to block YouTube for all your users but allow it when it's linked from somewhere else.

I don't really have anything else to add other than that you can upload images here directly without having to link to some hosting site like Imgur. Just use the Upload Image button in the Edit bar when you're making a comment.

Hmm, then I would be testing against an external iperf server next if you can. Steve

to be honest any sort of nat "reflection" is just an abomination if you ask me.. Why not just have your local stuff resolve the local IP vs any sort of reflection off your public IP.. Simple host override is all it takes. Only reason I can think of doing a reflection would be to work around the horrible coding of some app that uses a IP vs a fqdn as destination.

Most of the ET Policy ones are related to my IOT network, I should really tighten up $home_net now I'm running Snort on the parent interface. The SIP stuff is related to a VOIP phone sat on my network. The rest was just normal day to day traffic.

Thx for the quick exact info!!

Thanks a lot i now understand it probably thru the console I also discovered in the link https://community.adamnet.works/hc/en-us/articles/115002725594-Running-on-a-Transparent-pfSense-Bridge It uses the mac address of both the WAN and LAN interface rather than ip address when assigning the LAN and WAN interface to the BRidge This has to be tested before knowing if it works

What is your hardware? Just how bad is you upload speed? How are you testing it? How fast is it without pfSense in line? Steve

Nope - not forced, you making the call that easier and better to nat then change one side to use something different.. Not like rfc1918 is freaking limited in what address space you can use ;)

That sort of thing is often achieved by using a very low TTL value to prevent routing. People occasionally ask about doing the opposite of this to bypass such restrictions. However I'm not sure there is any way to do that in pfSense. Not in the GUI at least. Steve

Are you using a static IP on WAN? Is it correct? If it's DHCP is it pulling the correct gateway? The gateway may not respsond to ping in which case it will always show as off-line. You would have to set a different monitor IP if that was the case. ... only in the host where the pfsense running Does that mean it's a VM? Are you sure the interfaces are configured correctly? Steve

If it got to the point where it can't load the kernel, I wouldn't settle for anything less than a wipe+reload. I'd also be suspicious of the disk itself.

The difference is that --comp-lzo is for all OpenVPN versions. --compress is for version 2.4 and higher. Also see the manual: https://community.openvpn.net/openvpn/wiki/Openvpn24ManPage

@Pippin I don't know if that is the proper fix. My thought would be to find out what's causing this. What packets are being fragmented? If that setting only affects fragmented packets that have DF set, then I suppose it wouldn't be a problem. Still, I'd want to know why it's needed. As I mentioned, DF is used these days, for everything on Linux and TCP on Windows.

So apparently their is a -L flag that can be used when executing the command to start the NTP daemon which will tell it not to listen on VIPs. However for this to work as such the alias for the VIP must have a colon in the name (which if you ask me is a very weird condition). Not to mention that they came its been depreciated and thus more preferable to use the -I flag to directly and more explicitly specify the exact interface(s)/IP(s) you want it to listen on. Just out of curiosity though if we can directly specify these things as part of the command to run NTP versus building a config file, putting these values into it, telling NTP to get that info from the config file, etc would it not just be easier/more efficient to build it all into a single command and have it run as such from the get go?