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

    IPSEC to CradlePoint...Tunnel Established But No Ping

    Scheduled Pinned Locked Moved IPsec
    17 Posts 2 Posters 2.3k 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.
    • B
      b_levitt
      last edited by

      Previously tried to create a watchguard to cradle point tunnel. Was successful but tunnel was unstable (probably due to old watchguard firmware). I say that only to show that i've been somewhat successful with the cradlepoint before.

      Replaced the watchguard with pfSense (gladly)....

      Tunnel between the two was MUCH easier to establish, but now I can't get any traffic to move over it (no ping).

      One odd thing to me is that packet capture shows ping leaving WAN interface, instead of ipsec interface.

      2_1532617632599_tunnel-SPD.JPG 1_1532617632599_tunnel-SAD.JPG 0_1532617632599_tunnel-rules.JPG

      1 Reply Last reply Reply Quote 0
      • B
        b_levitt
        last edited by

        By the way, not sure why there are duplicate SPDs.

        1 Reply Last reply Reply Quote 0
        • B
          b_levitt
          last edited by

          here's the cradlepoint log if it helps:

          Fri Jul 27 14:34:08 2018|DEBUG|psmon:racoonctl|Process (/usr/sbin/racoonctl[14042]) exited with code: 0
Fri Jul 27 14:34:07 2018|INFO|racoon|INFO: IPsec-SA established: ESP/Tunnel xx.xx.xx.37[500]->yy.yy.yy.130[500] spi=3467385732(0xceac1b84)
Fri Jul 27 14:34:07 2018|INFO|racoon|INFO: IPsec-SA established: ESP/Tunnel xx.xx.xx.37[500]->yy.yy.yy.130[500] spi=63186293(0x3c42575)
Fri Jul 27 14:34:07 2018|INFO|racoon|WARNING: attribute has been modified.
Fri Jul 27 14:34:07 2018|INFO|racoon|INFO: initiate new phase 2 negotiation: xx.xx.xx.37[500]<=>yy.yy.yy.130[500]
Fri Jul 27 14:34:07 2018|DEBUG|ipsec|Phase 1 Up: ['control', 'vpn', 'up', 0]: yy.yy.yy.130
Fri Jul 27 14:34:07 2018|INFO|racoon|INFO: ISAKMP-SA established xx.xx.xx.37[500]-yy.yy.yy.130[500] spi:54c9b19c72e8cd9a:c9c89441ec115fc6
Fri Jul 27 14:34:06 2018|INFO|racoon|INFO: NAT not detected
Fri Jul 27 14:34:06 2018|INFO|racoon|INFO: NAT-D payload #1 verified
Fri Jul 27 14:34:06 2018|INFO|racoon|[yy.yy.yy.130] INFO: Hashing yy.yy.yy.130[500] with algo #2
Fri Jul 27 14:34:06 2018|INFO|racoon|INFO: NAT-D payload #0 verified
Fri Jul 27 14:34:06 2018|INFO|racoon|[xx.xx.xx.37] INFO: Hashing xx.xx.xx.37[500] with algo #2
Fri Jul 27 14:34:06 2018|INFO|racoon|INFO: Adding remote and local NAT-D payloads.
Fri Jul 27 14:34:06 2018|INFO|racoon|[xx.xx.xx.37] INFO: Hashing xx.xx.xx.37[500] with algo #2
Fri Jul 27 14:34:06 2018|INFO|racoon|[yy.yy.yy.130] INFO: Hashing yy.yy.yy.130[500] with algo #2
Fri Jul 27 14:34:06 2018|INFO|racoon|[yy.yy.yy.130] INFO: Selected NAT-T version: RFC 3947
Fri Jul 27 14:34:06 2018|INFO|racoon|INFO: received Vendor ID: RFC 3947
Fri Jul 27 14:34:06 2018|INFO|racoon|INFO: received Vendor ID: DPD
Fri Jul 27 14:34:06 2018|INFO|racoon|INFO: received Vendor ID: draft-ietf-ipsra-isakmp-xauth-06.txt
Fri Jul 27 14:34:06 2018|INFO|racoon|INFO: begin Identity Protection mode.
Fri Jul 27 14:34:06 2018|INFO|racoon|INFO: initiate new phase 1 negotiation: xx.xx.xx.37[500]<=>yy.yy.yy.130[500]
Fri Jul 27 14:34:06 2018|INFO|racoon|INFO: IPsec-SA request for yy.yy.yy.130 queued due to no phase1 found.
Fri Jul 27 14:34:06 2018|DEBUG|psmon:racoonctl|Started process 14042: ['/usr/sbin/racoonctl', 'establish-sa', '-w', 'esp', 'inet', '192.168.0.0/24', '10.1.1.0/24', 'udp']
Fri Jul 27 14:34:06 2018|DEBUG|ipsec|bring up Office_To_Colo with 192.168.0.0/24->10.1.1.0/24
Fri Jul 27 14:34:06 2018|INFO|racoon|INFO: xx.xx.xx.37[500] used as isakmp port (fd=6)
Fri Jul 27 14:34:06 2018|INFO|racoon|INFO: xx.xx.xx.37[500] used for NAT-T
Fri Jul 27 14:34:06 2018|INFO|racoon|INFO: xx.xx.xx.37[4500] used as isakmp port (fd=5)
Fri Jul 27 14:34:06 2018|INFO|racoon|INFO: xx.xx.xx.37[4500] used for NAT-T
          1 Reply Last reply Reply Quote 0
          • B
            b_levitt
            last edited by

            Ok, i removed the cradlepoint from their remote management service, which allowed me to discover a firmware upgrade. It looks like it is now using strongswan instead of racoon. It gives me new info, but no new progress:

            Tunnel

            Tunnel Office_To_Colo (00000000-bb2b-3f16-b8bd-c1264651d390)
  enabled: True
  dead_peer_timeout: 27
  state: up
  Connection (00000000-bb2b-3f16-b8bd-c1264651d390)
    version: IKEv1
    local: ['xx.xx.xx.37']
    remote: ['yy.yy.yy.130']
    Child Configuration (00000000-bb2b-3f16-b8bd-c1264651d390)
      mode: TUNNEL
      local_ts: ['192.168.0.0/24[17]']
      remote_ts: ['10.1.1.0/24[17]']
    IKE SA (00000000-bb2b-3f16-b8bd-c1264651d390)
      state: ESTABLISHED
      version: IKEv1
      algorithms: AES_CBC, PRF_HMAC_SHA1, MODP_1024
      local: xx.xx.xx.37:500
      remote: yy.yy.yy.130:500
      lifetime_seconds: 635 of 80121
      Child SA (00000000-bb2b-3f16-b8bd-c1264651d390-15)
        state: INSTALLED
        algorithms: AES_CBC, HMAC_MD5_96, MODP_1024
        local_ts: ['192.168.0.0/24[17]']
        remote_ts: ['10.1.1.0/24[17]']
        lifetime_seconds: 635 of 43200
        data_in: 0 / 0
        data_out: 0 / 0
        spi_in: c51d4c3a
        spi_out: cf0e7bb3

            SPDs:

            "src 192.168.0.0/24 dst 10.1.1.0/24 proto 17 
	dir out priority 375167 
	tmpl src xx.xx.xx.37 dst yy.yy.yy.130
		proto esp spi 0xcf0e7bb3 reqid 7 mode tunnel
src 10.1.1.0/24 dst 192.168.0.0/24 proto 17 
	dir fwd priority 375167 
	tmpl src yy.yy.yy.130 dst xx.xx.xx.37
		proto esp reqid 7 mode tunnel
src 10.1.1.0/24 dst 192.168.0.0/24 proto 17 
	dir in priority 375167 
	tmpl src yy.yy.yy.130 dst xx.xx.xx.37
		proto esp reqid 7 mode tunnel"	"src xx.xx.xx.37 dst yy.yy.yy.130
	proto esp spi 0xcf0e7bb3 reqid 7 mode tunnel
	replay-window 0 flag af-unspec
	auth-trunc hmac(md5) 0x9556afb101bf2619229173f0dfa17a38 96
	enc cbc(aes) 0xb1c0cc12fa2f2ee6417a410aa5b04ca2
	anti-replay context: seq 0x0, oseq 0x0, bitmap 0x00000000
src yy.yy.yy.130 dst xx.xx.xx.37
	proto esp spi 0xc51d4c3a reqid 7 mode tunnel
	replay-window 32 flag af-unspec
	auth-trunc hmac(md5) 0x5d055d62880f2f086755883b9ff6a247 96
	enc cbc(aes) 0x7c56d223f52691b85d19a918d18c564f
	anti-replay context: seq 0x0, oseq 0x0, bitmap 0x00000000"

            SADs

            "src 192.168.0.0/24 dst 10.1.1.0/24 proto 17 
	dir out priority 375167 
	tmpl src xx.xx.xx.37 dst yy.yy.yy.130
		proto esp spi 0xcf0e7bb3 reqid 7 mode tunnel
src 10.1.1.0/24 dst 192.168.0.0/24 proto 17 
	dir fwd priority 375167 
	tmpl src yy.yy.yy.130 dst xx.xx.xx.37
		proto esp reqid 7 mode tunnel
src 10.1.1.0/24 dst 192.168.0.0/24 proto 17 
	dir in priority 375167 
	tmpl src yy.yy.yy.130 dst xx.xx.xx.37
		proto esp reqid 7 mode tunnel"	"src xx.xx.xx.37 dst yy.yy.yy.130
	proto esp spi 0xcf0e7bb3 reqid 7 mode tunnel
	replay-window 0 flag af-unspec
	auth-trunc hmac(md5) 0x9556afb101bf2619229173f0dfa17a38 96
	enc cbc(aes) 0xb1c0cc12fa2f2ee6417a410aa5b04ca2
	anti-replay context: seq 0x0, oseq 0x0, bitmap 0x00000000
src yy.yy.yy.130 dst xx.xx.xx.37
	proto esp spi 0xc51d4c3a reqid 7 mode tunnel
	replay-window 32 flag af-unspec
	auth-trunc hmac(md5) 0x5d055d62880f2f086755883b9ff6a247 96
	enc cbc(aes) 0x7c56d223f52691b85d19a918d18c564f
	anti-replay context: seq 0x0, oseq 0x0, bitmap 0x00000000"
            1 Reply Last reply Reply Quote 0
            • B
              b_levitt
              last edited by

              still trying to figure this out...

              Can anybody tell me about the life vs install counter?:

              0_1533565259404_Capture.JPG

              1 Reply Last reply Reply Quote 0
              • DerelictD
                Derelict LAYER 8 Netgate
                last edited by

                First, uncheck Disable re-key on the Phase 1 and try again.

                From those counters it's pretty obvious you are sending traffic out the tunnel but nothing is coming back.

                Chattanooga, Tennessee, USA
                A comprehensive network diagram is worth 10,000 words and 15 conference calls.
                DO NOT set a source address/port in a port forward or firewall rule unless you KNOW you need it!
                Do Not Chat For Help! NO_WAN_EGRESS(TM)

                B 1 Reply Last reply Reply Quote 0
                • B
                  b_levitt @Derelict
                  last edited by

                  @derelict, ok unchecked disable rekey.

                  Not sure why there was no inbound in that screenshot: There is now but still can't get a ping:
                  0_1533577012390_Capture.JPG

                  1 Reply Last reply Reply Quote 0
                  • DerelictD
                    Derelict LAYER 8 Netgate
                    last edited by

                    Exactly what are you pinging from where? IP addresses please.

                    Chattanooga, Tennessee, USA
                    A comprehensive network diagram is worth 10,000 words and 15 conference calls.
                    DO NOT set a source address/port in a port forward or firewall rule unless you KNOW you need it!
                    Do Not Chat For Help! NO_WAN_EGRESS(TM)

                    1 Reply Last reply Reply Quote 0
                    • B
                      b_levitt
                      last edited by

                      the internal networks from both sides:
                      10.1.1.1 (pfsense lan ip) from 192.168.0.2 (cradlepoint lan ip) (and vice versa)
                      192.168.0.2 from 10.1.1.2 (server using pfsense as gateway) (and vice versa)
                      192.168.0.147 (static route added for 10.1.1.0 via 192.168.0.2) from 10.1.1.2 (and vice versa)

                      1 Reply Last reply Reply Quote 0
                      • DerelictD
                        Derelict LAYER 8 Netgate
                        last edited by

                        Are you policy routing (gateways set on rules) on the 10.1.1.X interface?

                        If you are testing pings from the firewall are you positive you are sourcing from an interesting address/interface on the local side of the tunnel?

                        Chattanooga, Tennessee, USA
                        A comprehensive network diagram is worth 10,000 words and 15 conference calls.
                        DO NOT set a source address/port in a port forward or firewall rule unless you KNOW you need it!
                        Do Not Chat For Help! NO_WAN_EGRESS(TM)

                        B 1 Reply Last reply Reply Quote 0
                        • B
                          b_levitt @Derelict
                          last edited by

                          I'm not sure I know how to answer that...I'm not using VTI if that is what you mean. My assumption (forgive my limited knowledge) is that traffic will be routed over the tunnel based on the networks specified in the phase 2 parameters. Is this not correct? Let me put it this way...I've followed half a dozen pfsense standard tunnel ipsec tutorials looking for any steps related to routing that I may have missed and they are all the same...just getting the p1/p2 params to match and adding the rule to allow ipsec traffic.

                          I'm testing from everywhere. I did find a section in the pfsense book about adding a "fake" route and gateway for the sake of pinging right from pfsense, but that didn't help.

                          https://portal.pfsense.org/docs/book/ipsec/site-to-site.html#pfsense-initiated-traffic-and-ipsec

                          However, i continue to try from both the pfsense, cradlepoint, and other servers just to make sure it's not working in one place but not others.

                          1 Reply Last reply Reply Quote 0
                          • DerelictD
                            Derelict LAYER 8 Netgate
                            last edited by Derelict

                            Looking for the reason the traffic is going out WAN. In general that means:

                            1. You are policy routing on the LAN interface so the traffic is being told to go a particular direction and is not caught by the IPsec traffic selectors.
                            2. You are testing sourcing from an address that is not included in the traffic selectors. This is common when you use Diagnostics > Ping on the firewall and don't set LAN as the source interface, etc.

                            I am just going on what you said here:

                            One odd thing to me is that packet capture shows ping leaving WAN interface, instead of ipsec interface.

                            Chattanooga, Tennessee, USA
                            A comprehensive network diagram is worth 10,000 words and 15 conference calls.
                            DO NOT set a source address/port in a port forward or firewall rule unless you KNOW you need it!
                            Do Not Chat For Help! NO_WAN_EGRESS(TM)

                            1 Reply Last reply Reply Quote 0
                            • B
                              b_levitt
                              last edited by

                              Yeah, that was probably before I understood the fluke with traffic originating from the pfsense itself (i only bought the gold/book today). I just ran another ping from a server and do see the traffic on the ipsec interface in the packet capture.

                              1 Reply Last reply Reply Quote 0
                              • DerelictD
                                Derelict LAYER 8 Netgate
                                last edited by

                                If there is no response you need to look at the other side.

                                Chattanooga, Tennessee, USA
                                A comprehensive network diagram is worth 10,000 words and 15 conference calls.
                                DO NOT set a source address/port in a port forward or firewall rule unless you KNOW you need it!
                                Do Not Chat For Help! NO_WAN_EGRESS(TM)

                                1 Reply Last reply Reply Quote 0
                                • B
                                  b_levitt
                                  last edited by

                                  yeah, i agree. I just discovered that the firmware upgrade on the cradlepoint gave me a similar packet capture functionality, and I can see the inbound ICMP packets.

                                  Thank you much for helping me get this far.

                                  1 Reply Last reply Reply Quote 0
                                  • B
                                    b_levitt
                                    last edited by

                                    ok, this is comical...deleted the tunnel off the cradelpoint, recreated it, and now it works. I know I've tried that before, but maybe, that in combination with the firmware upgrade fixed it.

                                    1 Reply Last reply Reply Quote 0
                                    • DerelictD
                                      Derelict LAYER 8 Netgate
                                      last edited by

                                      Glad you got it working. Thanks for letting us know.

                                      Chattanooga, Tennessee, USA
                                      A comprehensive network diagram is worth 10,000 words and 15 conference calls.
                                      DO NOT set a source address/port in a port forward or firewall rule unless you KNOW you need it!
                                      Do Not Chat For Help! NO_WAN_EGRESS(TM)

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