@bmeeks I will take a look at the links later - thanks. 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.

Deleting your original question and not stating how you fixed it wont help anyone else facing the same issue.

@mrbankheadgmail-com I know this topic is quite old, but I'm experiencing the same thing on multiple proxmox hosts and pfSense. Did you ever find a solution?

@kiokoman Thanks! It's solved!!

Hello epasinetti, 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: Interface:WAN Source:10.0.2.100/32 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.

Lazy me would just throw another whole 512MB RAM (or even 256) at the Hyper-V install and chalk it up to differences in the emulation/implementation of the V-nics. Or just go back to VMWare.

I create a new VM with 1024 MB and now i have zero problem. Thanks for your help :)

instructions https://docs.netgate.com/pfsense/en/latest/virtualization/virtualizing-pfsense-with-vmware-vsphere-esxi.html