Remote Networking

Reply
Contributor I

RAP-2WG Failing IKE P1 Over Comcast Broadband

Hi folks....

I've recently built out a 650 controller in order to begin piloting the RAP technology. I am using cert-based auth between the controller and the RAP model 5 and 2 AP units. This proved a success in every case where the connection used a DSL ISP, but met with an 80% failure rate when attempted over a Comcast broadband ISP connection. The 20% success with Comcast was an isolated incident where the subscriber elected to use his own broadband modem instead of the leased units from Comcast. At first, I thought it might be because the leased modem was providing the digital VoIP service, but one of the failed attempts was basic cable/high-speed internet subscription w/o voice, hd, or digital. The error that I get when RAP-Controller IPSEC negotiation occurs is:

Mar 15 09:12:19 :103060: |ike| ike_phase_1.c:ike_phase_1_responder_recv_SA:1041 Ike Phase 1 received SA

Mar 15 09:12:23 :103060: |ike| ike_phase_1.c:ike_phase_1_responder_recv_SA:897 Recvd VPN IKE Phase 1 SA transform negotiation (1st packet) from IP 67.233.140.44.
Mar 15 09:12:23 :103060: |ike| ike_phase_1.c:ike_phase_1_responder_recv_SA:926 Found our AP vendor ID from external IP 67.xxx.xxx.44
Mar 15 09:12:23 :103060: |ike| ike_phase_1.c:attribute_unacceptable:2847 Proposal match failed in key length, configured=32, peer using=16
Mar 15 09:12:23 :103060: |ike| ike_phase_1.c:attribute_unacceptable:2818 Proposal match failed in auth algo, configured=PRE_SHARED, peer using=IKE_AUTH_XAUTHINIT_RSA_SIG
Mar 15 09:12:23 :103060: |ike| ike_phase_1.c:attribute_unacceptable:2807 Proposal match failed in hash algo, configured=SHA, peer using=MD5
Mar 15 09:12:23 :103060: |ike| ike_phase_1.c:attribute_unacceptable:2847 Proposal match failed in key length, configured=32, peer using=24
Mar 15 09:12:23 :103060: |ike| ike_phase_1.c:attribute_unacceptable:2818 Proposal match failed in auth algo, configured=PRE_SHARED, peer using=IKE_AUTH_XAUTHINIT_RSA_SIG
Mar 15 09:12:23 :103060: |ike| ike_phase_1.c:attribute_unacceptable:2807 Proposal match failed in hash algo, configured=SHA, peer using=MD5
Mar 15 09:12:23 :103060: |ike| ike_phase_1.c:ike_phase_1_responder_recv_SA:1041 Ike Phase 1 received SA

Since this is limited to comcast connections, i wanted to insure it wasn't home routers so I bypassed my router and plugged the RAP directly into the comcast modem in order to take this extra piece of hardware/software out of the equation but the results are the "same". Any ideas or shared experiences related to this would be deemed HELPFUL. I have a case open with COMCAST but don't know how many tiers it will have to escalate before I find someone knowledgeable in IPSEC and NAT-T. Thanks in advance!

Bruce
Guru Elite

Re: RAP-2WG Failing IKE P1 Over Comcast Broadband

What version of ArubaOS is this? What is the topology? Is the 650 behind a firewall doing 1:1 NAT or is it a public address?


Colin Joseph
Aruba Customer Engineering

Looking for an Answer? Search the Community Knowledge Base Here: Community Knowledge Base

Contributor I

Questions Answered...

Colin:

This is a 650 controller (host) with a public facing IP address. Don't lose sight of the fact that this works over CenturyLink DSL without any problems. I've located the RAP directly connected to Comcast's MODEM bypassing my own home wlan router (Netgear) so I've taken that out of the equation. The only success I've had with Comcast as the carrier was at an Aruba SE's home and he had his own modem as opposed to the leased modem. I've gone one step further and directly attached the RAP to the controller and performed an OS upgrade locally, furthermore, I've pushed this image to the boot partition on the RAP so that it now boots up under 5.0.3.0 image. Still failing at IKE P1. I've opened a ticket with Comcast 3 days ago and still haven't heard from them. This doesn't seem like an Aruba issue (based on the above), but was more interested in anyone else experiencing the same issue. In reading several posts, its obvious I'm not the only one dealing with this issue. If you look at the output I posted, you can see that the proposed methods for IKE P1 are different between the controller and the RAP. If this RAP has been directly connected to the controller and received its config/image, then wouldn't it be safe to assume that the IKE negotiation /reqs/process would already be established on both ends?
Guru Elite

Re: RAP-2WG Failing IKE P1 Over Comcast Broadband

- Incoming IPSEC connections are always negotiated, without exception, so you will see the same messages, no matter what.
- The most definitive test would be to do a wired packet capture at the AP and at the controller and compare it to a successful test.
- The symptoms you mention are indicative of one-way connectivity, where the traffic sent never gets back to the AP, hence the IKEP1 message

If you do the wired packet capture above, both at the AP and at the controller, you would be able to confirm if that is the case. I am not saying there is or is not an issue with comcast, but with limited knowledge of your situation, a packet capture will speak volumes.

We have deployed RAP technology in thousands of locations and if there was a specific issue with Comcast, it should have come up by now in a big way. If you need this taken care of ASAP, and it seems you do, please open a case with support so that they can get into the particulars of your situation. I would only be guessing based on what you tell me here.


Colin Joseph
Aruba Customer Engineering

Looking for an Answer? Search the Community Knowledge Base Here: Community Knowledge Base

Contributor I

Thanks For the Reply...

Colin:

It would seem likely that this would have created a scat-storm with Comcast as the ISP. I had already planned on doing the wireshark capture. I've also had a ticket open with Aruba for over a month now. The biggest problem with that is it seems Aruba wants me to be in 2 places at one time in order to effectively t-shoot. They want me at the remote ap end (home) and they also want me in the telecom closet at work (public facing controller end).

Looks like if I can't derive a resolve, I might go in a new direction of using USB-3G and limiting the RAP service to the RAP-5s and do away with the RAP-2 until Aruba releases the new models with USB uplink capability.

Thanks for your assistance and references.

Regards,

Bruce
Guru Elite

Re: RAP-2WG Failing IKE P1 Over Comcast Broadband

The reason why Aruba wants packet captures at both ends is that they want to make sure that the traffic is being sent and received at both ends, without alteration or being dropped. If there is an issue such as MTU or some sort of filtering that is taking place, that will determine that. If you can also filter just one side, that would also give some perspective. The IKEP1 message means that traffic is simply not coming back.....


Colin Joseph
Aruba Customer Engineering

Looking for an Answer? Search the Community Knowledge Base Here: Community Knowledge Base

Search Airheads
cancel
Showing results for 
Search instead for 
Did you mean: