IPSEC to CradlePoint...Tunnel Established But No Ping

b_levitt

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.

b_levitt

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

b_levitt

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

b_levitt

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"

b_levitt

still trying to figure this out...

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

Derelict

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.

b_levitt

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

Derelict

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

b_levitt

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)

Derelict

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?

b_levitt

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.

Derelict

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

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

b_levitt

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.

Derelict

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

b_levitt

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.

b_levitt

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.

Derelict

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