PfSense as NVA in Azure HELP PLS!!!



  • Hello folks,
    I need an advice about how to route traffic with pfsense in subnet inside Azure.
    I use pfsense as VPN GW (NVA) - IP 10.1.0.2/28
    The subnet in Azure where the VMs reside is 10.2.0.0/28

    I managed to setup a tunnel with a remote GW and because the other side accept only public IP addresses i can't use the private subnet 10.2.0.0/28 in the encryption domain.

    In pfsense Phase 2 i use NAT to send to the other side the public IP of Azure VMs.

    In azure I made Route table for the public IP addresses from the other side so the VMs subnet know their NVA GW.

    This works and when sending traffic from the VMs it goes through the tunnel.

    The bad stuff is that i don't receive reply's when i try to ping the other's side IP.

    I've checked rules and everything and the traffic stops at Pfsense and dos not forward it to the internal private subnet in Azure.

    I tested some port forwarding rules but without luck. Maybe I don't make em the right way.
    What confuses me is that the IPsec ph2 is using NAT to send Azures Public IPs.

    Please Assist Me on that Task

    Thanks In Advance !!!!

    Best Regards,
    Mladen


  • Netgate Administrator

    Can you ping across the tunnel to from pfSense itself in Diag > Ping if you select the LAN interface as source?

    Can you ping to other VMs in Azure from pfSense?

    If you run a packet capture on the IPSec interface whilst trying to ping from one of the other VMs do you see the requests go out and replies come back?

    Steve



  • Hello Steve,
    Thank you for the answer. I can ping the VMs in Azure from PFsense. I configured PFSense as "router on a stick" so I have have only WAN interface .
    When use packet tracer it outputs traffic going in one direction VM>to>theMachine, on the other side of the tunnel.
    My guess is that I don't receive reply's because of a firewall on the other side.
    Best Regards,
    Mladen


  • Netgate Administrator

    Yes, most likely is the hosts on the other side are either not responding because of some local firewall rule there or they are missing a route and responses don't go back over the tunnel.
    Either way it would need to be confirmed at the remote end.

    Steve



  • Hello Stephenw10, HAPPY NEW YEAR !!! I WISH YOU HEALTH AND LUCK !!!

    Thank you for the reply and sorry for my late reply.

    We still didn't fix it, because the other side is missing an "behind keyboard device" :)

    I will write you when we have results !

    Thank you again and have all the best.

    Regards,
    Mladen


Log in to reply