IPSEC to CradlePoint...Tunnel Established But No Ping



  • 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



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



  • 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
    
    


  • 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"
    


  • still trying to figure this out...

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

    0_1533565259404_Capture.JPG


  • Netgate

    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.



  • @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


  • Netgate

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



  • 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)


  • Netgate

    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?



  • 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.


  • Netgate

    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.



  • 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.


  • Netgate

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



  • 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.



  • 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.


  • Netgate

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