As for a backup config.xml - this was a clean HA install, so the config should also be clean, however I have resolved the proxying issue, the ports being blocked I believe is more firewall related since I cannot connect to those IPs internally either, which do not go through the proxy, but will go to PfSense as a gateway.
I appreciate the help, but I think for the most part I have moved on from this for now, my only real issue is one I can bear with for now since I have used different IPs.
I thought AES-NI was going to be required from pfSense 2.5 onwards? At least it doesn't seem to be discouraged...
I confirmed my LiveCD findings, however, by disabling cryptodev in the "Advanced" section of the KVM virtualized pfSense instance, leaving only AES-NI. OpenSSL runs at host-comparable speeds now. Use of the cryptodev module is what makes it slow.
I have not attempted this yet. I never heard from anyone. I have submitted requests to the pfSense team to ask if they would officially offer one but I was told that it was not currently planned. I am sure that I could get it working as you can connect to the instance at OCI via a serial connection which is needed for the installation. I'd prefer to have an officially supported one which I could receive support for and would pay (just as I currently do for the physical deployment which my company uses).
The support from Netgate for pfSense is actually really good. They really know their stuff and responded quickly. I wish I had this quality of support from other vendors. It's money well spent.
Try to do an outbound NAT rule in Pfsense. It seems azure will not like if the source IP is not the WAN IP. When a packet goes out public (in Azure VM) it wants the source IP to be same as the interface IP.
So in your example, if your pfsense WAN interface IP (in azure) is 10.0.1.4 and if your VM (the one you want to be behind pfsense) LAN IP is 10.0.2.100 You need to setup a NAT rule in pfsnese where:
Port: up to you, you can do wildcard if you like
NAT Address: 10.0.1.4
So what this rule does is everything comes from the VM 10.0.2.100 that tries to go out on the WAN port (internet access) it will turn the source header IP (in the data packet) to 10.0.1.4 (which at that point, Azure would think that the packet is coming from the wan INTERFACE. Which then would allow it to go out.
I am no Azure expert, maybe someone has a better solution, but this is what I am using now.
But FYI, in the end, I am no longer using pfsense as the fireall. I am currently using Azure's firewall. I am simply using pfsense so that in can connect IPSEC with other company as Azure's own Virtual gateway is limited in IPSEC capability.
So your saying pfsense without any dns is reaching out to a specific IP? So the IP must be hard coded into pfsense to check for X?
I don't think so to be honest, hard coding IPs is horrible coding!
Lets see these logs, or the IP that its reaching out to.. And we can prob figure out what is going on.. But I would be very surprised if the pfsense dev's hardcoded an IP into anything they are running. Best would also be these sniffs you took.
You have no packages installed?
You sure its just not the ping to the gateway of pfsense wan? That would be reaching out to an IP without dns to resolve it.. You do know that pfsense even if you turn off unbound, will try and grab dns from dhcp on its wan. And then would attempt to use that for dns..
Also how are you sure its not something on the lan side trying to get to X?
What about NTP? If pfsense at any time had dns, it would of resolved some IPs in the ntp.pool and be trying to set time with those, etc.
TL;DR going to need way more info to try and help you figure out what your seeing.
Also, I have a few pfsense vms I could fire up and try and duplicate what your doing/seeing..
i am also having issue with carp running kvm/qemu with libvirt.
the devices see each other and choose master and slave respectively but if i turn one off the clients cannot access the virtual ip anymore.
is this fix applicable in my case and if so how do i do it?
I came across similar NIC ordering issue some time ago. When I added more than 4 vmxnet3 adapters to the machine, FreeBSD numbered interfaces differently in comparison to VM ethernet adapter order, that issue is described here. When I used E1000 interfaces, the problem disappeared. I had to use workaround script that renamed vmx interfaces in FreeBSD based on their mac address, so that interface order was the same on VM and FreeBSD.
This is however something different. I'm not touching interfaces on the VM, I'm just unassigning/disabling interfaces in pfSense GUI under Interfaces -> Assignments. Though it definitely bears some similarity with aforementioned NIC order bug (meaning that everything is fine with only 4 interfaces on the machine).
We provide leading-edge network security at a fair price - regardless of organizational size or network sophistication. We believe that an open-source security model offers disruptive pricing along with the agility required to quickly address emerging threats.
Subscribe to our Newsletter
Product information, software announcements, and special offers. See our newsletter archive to sign up for future newsletters and to read past announcements.