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

    I've never done IKE Phase II like this before, Can anyone help?

    Scheduled Pinned Locked Moved IPsec
    10 Posts 2 Posters 2.5k Views
    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.
    • L
      linuxg33k
      last edited by

      I've used PFSense for about 8 years.  I've built a lot of tunnels using this firewall to devices such as SonicWall, Cisco PIX and ASA's, however, I've never done one quite like this.  I was tasked with creating a tunnel for a client.  IKE Phase I is pretty straight forward to the client's Cisco ASA.  The tunnel is up, however, when I attempt to ping the remote host which is on 192.168.22.x/32, I cant get to it from my LAN segment which resides on 192.168.xxx.x/23.  When I ping the host on the remote network of 192.168.22.x/32 from my WAN interface on the PFSense, I get responses.  Here is how I was advised to set up IKE Phase II:

      Mode = Tunnel IPv4
      Local Network Type = Address
      Local Network Address= My WAN IP <– which is confusing me as this is usually the Local LAN subnet
      NAT/BINAT = None
      Remote Network Type = Address
      Remote Network Address = 192.168.22.x/32 <--- Single host

      ESP
      AES 256
      SHA 1
      PFS = Off
      28800

      Again, the tunnel is up and when I ping the remote host address (/32) from the WAN interface on the firewall, I get responses, but I cannot ping it from the LAN segment and I cant pass any traffic to it from the LAN.  I have 4 other active IPSec tunnels that function properly and I'm using OpenVPN for my mobile warriors.  I have firewall rules set up to allow all on the IPSec tab, but I'm wondering if I am just missing something simple.

      Any help is greatly appreciated.

      1 Reply Last reply Reply Quote 0
      • M
        mikee
        last edited by

        You don't disclose what the local network is. 192.168.xxx.x/23 could be anything including 192.168.22.0/23. As you may already know the /23 mask includes both networks 22 and 23 (I mean the network range goes from 192.168.22.0 to 192.168.23.255) so the destination host IP address may be in the same network and then it will normal that it is pingable from the wan interface of the router (that, evidently must has an IP address in the same network).

        So to be able to understand what you are confronting to we need first to know the addressing/routing scheme you are facing.

        1 Reply Last reply Reply Quote 0
        • L
          linuxg33k
          last edited by

          thanks for your response.  My addressing scheme is as follows:

          My LAN resides on 192.168.22.0/23 which does encompass the 22.0 and 23.0 subnets.  The client only granted us access to specific hosts on their network which reside at 192.168.44.192 and 192.168.46.95.  The resources on my network that need to access the remote resources at 44.192 and 46.95 reside on my LAN which is 22.0/23.

          In my first IKE phase II negotiation, I've defined one phase II negotiation with a remote address of 192.168.44.192 and in the LAN section of the phase II negotiation, I was instructed to add my WAN IP address.  In the second phase II negotiation, I've defined the remote address of 192.168.46.95 and in the LAN section, I again was instructed to place my WAN IP address.  While testing across the tunnel which is up, I can ping the remote single host IPs defined in each phase II from my firewall's WAN interface, but I cannot pass traffic to those hosts from the 192.168.22.0/23 network at all.

          Does this help?

          1 Reply Last reply Reply Quote 0
          • M
            mikee
            last edited by

            What you tell in your las message does not match with what you told in your first one.

            Anyway let us  to try to move on. You mention that you can ping the tunnel endpoints -192.168.44.192 and 192.168.46.95-. Can you assess that the ASA has two tuples of SAs to the pfSense and that the pfSense has SPDs for both tunnels (status->ipsec) and the SADs show data counters different than zero?

            Are the ASA's SAs encap and decap counters move more or less syncronously? (more or less the same number of packets processed).

            The former tests should be ok if the VPN is up and able to move data as you mention. Then if no traffic flows check that you allow data from the local lan into the tunnels. You must have a rule in the LAN interface allowing the traffic from your internal network (LAN subnet) to the remote internal networks (192.168.44.0/24 and 192.168.46.0/24). Do you have it?

            The same applies to the ASA side.

            1 Reply Last reply Reply Quote 0
            • L
              linuxg33k
              last edited by

              I will check this and reply as soon as possible, thanks for your help.

              1 Reply Last reply Reply Quote 0
              • L
                linuxg33k
                last edited by

                Yes, I do have a firewall rule on the lan allowing traffic to that destination host across that tunnel, but I'm still unable to reach the remote end devices.  I did check for SAD's and I can see both of them there from my WAN to the remote WAN, but neither are accruing any traffic, just a few b's.

                1 Reply Last reply Reply Quote 0
                • M
                  mikee
                  last edited by

                  Enable logging on that rule. Can you see hits in the log associated to your rule?

                  1 Reply Last reply Reply Quote 0
                  • L
                    linuxg33k
                    last edited by

                    Thanks for your patience and assistance.  It turns out that the client was asking for something that I was familiar with, however did not word it correctly.  The client was asking for us to NAT our traffic through the tunnel.  Being as our internal network gets defined on the Phase 2 negotiation, its already NAT'd.  What the client meant to say was, "We need you to NAT your public IP for phase 2 of the negotiation."  Once I realized what they truly meant, I was able to do this in 2.1 with ease and bring the tunnels up accordingly with multiple phase 2 negotiations defined for single host targets in the client's environment.  This was as simple as doing NAT before IPSec in 2.1 which works very well might I add.

                    Thanks,

                    1 Reply Last reply Reply Quote 0
                    • M
                      mikee
                      last edited by

                      Glad to see that you were finally able to overcome the problem.

                      Thanks for giving this feedback.

                      1 Reply Last reply Reply Quote 0
                      • L
                        linuxg33k
                        last edited by

                        Thanks for taking the time to walk through it with me.  Much appreciated.

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