Pfsense in Azure - Cannot reach host on IPsec tunnel
-
You need the static route in Azure otherwise VMs there have no way to reach the subnet over the VPN.
You only need a static route in pfSense for services on the firewall itself. It is not required for connectivity from other VMs.
You cannot have a NAT rule on the IPSec interface it will break the traffic. If you need NAT between those subnets though it should be in the IPSec P2 config. You probably don't need it though, since those subnets do not overlap, unless the other side is configured for some other subnet.
Other than that you just need to have firewall rules to allow the traffic into the firewall on LAN.
Steve
-
Hey Stephen,
I'm a little lost here, the traffic is being captured on the firewall and it is being allowed on both sides so it doesn't seem to be a firewall blocking issue. I have also turned off windows firewall on the test vm for testing purposes.
I've now changed the NAT outbound to automatic mode but it hasn't made any difference.
I still get this response "Destination host unreachable." when i try to tracert to the server on other side of tunnel from test vm.
I am not sure what else i can change?
thanks
Ben -
Ok so start a continuous ping to the VM in Azure from the other side of the tunnel. Now run pcaps on the IPSec and then LAN interfaces filtered by the source IP you're pinging from.
Do you see the pings in both pcaps?
If it's not leaving the LAN check the WAN. We have seen Azure do some weird things with traffic like that.
Steve
-
so in IPsec pcaps if i ping pfsense LAN address it comes up but if i ping the test VM it doesn't.
if i do the same for LAN pcaps nothing comes up for LAN address or test VM
If i change to WAN neither come up but the public IP address on the other side of the tunnel comes up when i don't run any ping commands.
thanks
Ben -
So when you ping the VM IP from the remote end of the tunnel that traffic never arrives over IPSec at the pfSense instance in Azure?
Then something is blocking it at the remote end or the VPN is not configured correctly so it doesn't carry that traffic.
Steve
-
Hi Steve,
"the VPN is not configured correctly so it doesn't carry that traffic." - the pfsense VPN or the VPN we have on other side? I have followed all of the instructions from numerous videos (which all seem to be different) and numerous online guides and what you've said above so what else could it be? My only guess is routing under 'system' or NAT under 'firewall' but i have tried numerous different settings but it has made no difference other than breaking it further.
"Then something is blocking it at the remote end" i have the firewall switched off on the test vm and the vm on other side of tunnel so it shouldn't be being blocked.
Do you have any other suggestions what could be causing this?
thanks
Ben -
The configured phase 2 policy has to carry the traffic you are sending. If it doesn't match it won't see the traffic as interesting and it won't grab it and send it over the tunnel.
The defined P2 has to match at both ends or it won't establish. We know it is established since you could ping over it from pfSense itself but what exactly has it established as? pfSense will allow a P2 to establish that is a smaller subnet defined within whatever it has configured. So for example if pfSense has 10.239.0.0/16 defined as the local subnet and the other end has 10.239.3.0/24 pfSense will allow the /24 to establish but of course that will not carry traffic from anything else in the /16.
Looking back your LAN IP is 10.239.3.5 but the VM you are trying to connect from/to is in a different subnet so the established P2 might not carry that.
Show us the established P2.
You also mentioned adding NAT in the P2 but I don't see that other than the actual NAT rule which was breaking things.
Additionally it's not clear why pfSense was ARPing for 10.128.2.181. It must have an interface in that subnet for that to happen.
Steve
-
ok here is the established P2:
the local subnets doesn't look right as i would expect to see the range there but even if i change this it doesn't make much difference
what do you mean by "Looking back your LAN IP is 10.239.3.5 but the VM you are trying to connect from/to is in a different subnet so the established P2 might not carry that.". I am trying to test connection to the vm on other side of tunnel with a vm in a different network in azure.
doing a packet capture now i can't see it ARPing anymore it just shows this:
17:17:00.607947 IP 10.233.2.4 > 10.239.3.5: ICMP echo request, id 1, seq 710, length 40
17:17:01.615256 IP 10.233.2.4 > 10.239.3.5: ICMP echo request, id 1, seq 711, length 40
17:17:01.772138 IP 10.233.2.4 > 10.128.2.181: ICMP echo request, id 1, seq 712, length 72
17:17:05.778564 IP 10.233.2.4 > 10.128.2.181: ICMP echo request, id 1, seq 713, length 72 -
Where are you running that packet capture?
We might need a diagram detailing the subnets involved here. The IP you are pinging from, 10.233.2.4, is not in any of the subnets carried by the P2. It cannot cross the VPN.
If that is another subnet is Azure you will need another P2 defined to carry it like 10.233.2.0/24 to 10.128.2.0/24.
The pfSense LAN IP should respond to ping though if that subnet is on the same end of the tunnel as long as it gad rules to allow that and a route back.
Steve
-
I was doing the pcap in pfsense on the LAN interface
Oh i see, so you need a P2 for each subnet involved. I've copied the setting from the original P2 and added in this subnet but it doesn't seem to have made much difference. it doesn't appear under SA either. Should it display all P2's?
I've also noticed setting up another P2 and then disconnecting then connecting the ipsec tunnel seems to take over the original p2 and take that one offline and it still doesn't seem to connect to this other 233 network.
do i need to setup a static route for each subnet/network ?
i've noticed that the reason why it was ARP'ing before was because i had this static route setup and so when i set it to disabled i just see ICMP requests come up on the lan pcap.
-
You may need a route to 10.233.2.0/24 if that is not accessible via the default route but only then.
I assume you can access the pfSense webgui from 10.233.2.4?
Otherwise you would only need those routes to establish connections over the VPN from the firewall itself rather than from hosts behind it.
Your screenshot where you have 10.233.2.0/24 in the P2, which is required, shows 0 packets in or out on it but it also shows as established for 0 seconds. If you have that up, or both P2s there, and send traffic from either end do you see the packet counter increase in either direction?
Steve
