Netgate Discussion Forum
    • Categories
    • Recent
    • Tags
    • Popular
    • Users
    • Search
    • Register
    • Login

    Help: Terminate IPSEC Clients to NATed WAN address

    NAT
    2
    4
    5.2k
    Loading More Posts
    • Oldest to Newest
    • Newest to Oldest
    • Most Votes
    Reply
    • Reply as topic
    Log in to reply
    This topic has been deleted. Only users with topic management privileges can see it.
    • P
      pakroby
      last edited by

      I am running v1.2.3rc1 on VMWare ESXi with promiscuous enabled.

      I have a.b.c.72/27 on my WAN interface
      I want to set up a.b.c.77 as the 'local subnet' for my IPSEC connections, and I want it to PAT/NAT to various ports and addresses on the LAN interface.  The IPSEC end point, or local subnet, needs to be one of my internet IP addresses because I will need to maintain many IPSEC connections from various networks and I must ensure that the local subnet is a unique address.

      I have been at this for a while and have not been very successful in my efforts, or in finding information on how to accomplish this specific task.

      Can anyone offer any insight or advice?

      Thanks in advance.

      1 Reply Last reply Reply Quote 0
      • P
        pakroby
        last edited by

        26 Views and no replies.  Is it that hard, or am I that dumb?

        If i set up a CARP address on my WAN, and point my IPSEC clients there should NAT reflection take care of me, or should I turn on AON and set up my own outbound NAT rules?

        I have been having the darnedest time just trying to get a standard port forward working from a CARP on the WAN to the LAN, let alone getting NAT reflection to work accost my IPSEC VLAN.

        –---edit/append-----
        I realize that the description may not make complete sense so I have added the diagram below. 

        So you can see I have a CARP address setup on pfSense.  I want my IPSEC clients to terminate to this as their remote network, and then I want to PAT x.x.x.77 out to various places on the LAN.  I am not even sure if the CARP should be on the WAN or the LAN considering how I want to use it.  Also, x.x.x.77 is only to be accessed from IPSEC clients, if that makes any difference.

        1 Reply Last reply Reply Quote 0
        • E
          Eugene
          last edited by

          I am sorry but I personally do not understand what you are trying to achieve.
          Small clouds with VPN - are these VPN clients? Why do you mention CARP here at all?

          http://ru.doc.pfsense.org

          1 Reply Last reply Reply Quote 0
          • P
            pakroby
            last edited by

            So I have managed to get a test VPN connection up to a SonicWALL TZW.  I have NAT reflection enabled to make the xxx.xxx.xxx.77 address accessible from inside the firewall.  The problem that I am running into now is that I can only bring the tunnel up from the TZW side by pinging the xxx.xxx.xxx.77 address from inside the LAN of the TZW.  I need to be able to bring it up from the pfSense side as well, but I am unable to ping the remote network (192.168.41.0/24) of the TZW from pfSense.

            It seems like maybe an outbound NAT rule would take care of this, but I don't know how to set it up correctly, and it doesn't seem like I can make a outbound NAT rule for my IPSEC VLAN.  Can anyone help?

            Below are some screen shots of my current working configuration to help you better understand my setup.

            CARP Address on the WAN where VPNs will terminate.  This must be CARP as opposed to Proxy ARP because it needs to be pingable. 

            VPN with remote network set to WAN-CARP address

            Port forwarding xxx.xxx.xxx.77:22 to 192.168.41.50:22  This si working.  I can SSH to xxx.xxx.xxx.77: from the TZW and connect to a shell at xxx.xxx.xxx.50:22

            And here is the firewall rule that lets the port forwarding work. 

            1 Reply Last reply Reply Quote 0
            • First post
              Last post
            Copyright 2025 Rubicon Communications LLC (Netgate). All rights reserved.