Using PFSense as ipsec Endpoint of Azure
-
If you can ping an office machine from the server then you have some sort of route to reach it. However it may be an asymmetric route via the Azure gateway in which case ICMP might be allowed whilst TCP is blocked. Can you open any TCP connection from the server in Azure to any device on your office subnet?
It might be the local Windows firewall on the server blocking requests from outside it's subnet unless you've disabled that.
Steve
-
I was wrong. I can ping the server and the office machines from pfsense, but i can't ping the office machines from the azure server or the server from the office machines. Probably I made some routing mistakes in azure but I have no idea how to solve this.
-
The simplest solution, for just one server, might be to just add a route to the office subnet via the pfSense internal IP (192.168.5.10) on the server itself.
If you only need to connect to the server you can also NAT the traffic leaving the interface in pfSense. That will allow the server to reply as all traffic will appear to be from it's own subnet. It's ugly though!Steve
-
Thanks Steve. I try my best to set up the routes.
This is how my configuration looks like:
PFSense:
SPDs:
192.168.125.0/24 -> 192.168.5.0/24 // Tunnel endpoints: public-ip-office -> 192.168.4.10
192.168.5.0/24 -> 192.168.125.0/24 // Tunnel endpoints: 192.168.4.10 -> public-ip-officeAzure:
PFSense NIC1( 192.168.4.10):
effective routes:
192.168.4.0/23 -> virtual network
0.0.0.0 /0 -> internetPFSense NIC2(192.168.5.10) + ip-forwarding-enabled:
effective routes:
192.168.4.0/23 -> virtual network
192.168.125.0 -> virtual network
0.0.0.0 /0 -> 192.168.5.10Server NIC(192.168.5.100):
192.168.4.0/23 -> virtual network
192.168.125.0 -> virtual network
0.0.0.0 /0 -> 192.168.5.10It is still not working.^^
-
That /23 subnet seems suspect. That covers the subnets on both of the pfSense NICs. So how does pfSense know which NIC to use? You have the same route on two NICs there.
However if you can ping the server from pfSense itself I expect it to work.
You may have to run some packet captures to see where the pings are going once the come over the tunnel, or if they do come over the tunnel at all.
Steve
-
It was a wrong firewall setting. Now everything works fine. I just have to find out why the rdp ipsec connection is so slow.
Thank you very much
cheers nik
-
It's easy to get significant packet fragmentation over IPSec. Setting MSS clamping can improve things quite a bit if you tune it right with a packet capture.
Also make sure you're using the fastest encryption you can. IKEv2 with AES-GCM using AES-NI is usually what you want.
Enabling asynchronous-crypto in the IPSec advanced settings can dramatically improve speed on multicore CPUs but has been shown to cause issues in edge cases. Usually no traffic at all if you hit it.
Steve
-
Curious, did anyone ever get AES-GCM working with Azure? I tried and gave up.
-
With pfSense running in Azure? Which is was this thread is.
You can run any cipher you want, as long as the remote side supports it, Azure doesn't see that. It only sees the encrypted IPSec traffic.
Steve
-
Oh sorry. never mind then.
-
This post is deleted! -
I'm not aware of any issues using AES-GCM dircetly to Azure either.
But, yeah, better to start a new thread for that.
Steve
