NETGEAR is aware of a growing number of phone and online scams. To learn how to stay safe click here.
Forum Discussion
Solved
Getting SRX5308 VPN IPSec to work with Android (when using DynDNS)
Greetings, It appears that I can achieve a IPSec VPN Connection (both the Android device and the SRX5308 (with the latest firmware) confirm it), but there appears to be no traffic flowing through...
Questions, comments, difficulties?
Hmm, it's not liking that.
Here's the log output from attempting to VPN from one VLAN (VLAN 4) to another VLAN (VLAN 2) using a Google Pixel C:
Wed Nov 23 11:43:25 2016 (GMT -0500): [SRX5308] [IKE] WARNING: Ignored attribute 28678
Wed Nov 23 11:43:25 2016 (GMT -0500): [SRX5308] [IKE] ERROR: Local configuration for 192.168.4.21[500] does not have mode config
Wed Nov 23 11:43:25 2016 (GMT -0500): [SRX5308] [IKE] ERROR: Local configuration for 192.168.4.21[500] does not have mode config
Wed Nov 23 11:43:25 2016 (GMT -0500): [SRX5308] [IKE] ERROR: Local configuration for 192.168.4.21[500] does not have mode config
Wed Nov 23 11:43:25 2016 (GMT -0500): [SRX5308] [IKE] ERROR: Local configuration for 192.168.4.21[500] does not have mode config
Wed Nov 23 11:43:25 2016 (GMT -0500): [SRX5308] [IKE] ERROR: Local configuration for 192.168.4.21[500] does not have mode config
Wed Nov 23 11:43:25 2016 (GMT -0500): [SRX5308] [IKE] ERROR: Local configuration for 192.168.4.21[500] does not have mode config
Wed Nov 23 11:43:25 2016 (GMT -0500): [SRX5308] [IKE] ERROR: Local configuration for 192.168.4.21[500] does not have mode config
Wed Nov 23 11:43:25 2016 (GMT -0500): [SRX5308] [IKE] ERROR: Local configuration for 192.168.4.21[500] does not have mode config
Wed Nov 23 11:43:25 2016 (GMT -0500): [SRX5308] [IKE] INFO: Received attribute type "ISAKMP_CFG_REQUEST" from 192.168.4.21[500]
Wed Nov 23 11:43:25 2016 (GMT -0500): [SRX5308] [IKE] INFO: XAuthUser RemoteVossnetUser Logged In from IP Address 192.168.4.21
Wed Nov 23 11:43:25 2016 (GMT -0500): [SRX5308] [IKE] INFO: Login succeeded for user "RemoteVossnetUser"
Wed Nov 23 11:43:25 2016 (GMT -0500): [SRX5308] [IKE] INFO: Received attribute type "ISAKMP_CFG_REPLY" from 192.168.4.21[500]
Wed Nov 23 11:43:25 2016 (GMT -0500): [SRX5308] [IKE] INFO: ISAKMP-SA established for 93.225.201.7[500]-192.168.4.21[500] with spi:3eb246743e9a50e9:c75c6d96111f9919
Wed Nov 23 11:43:25 2016 (GMT -0500): [SRX5308] [IKE] INFO: Sending Xauth request to 192.168.4.21[500]
Wed Nov 23 11:43:25 2016 (GMT -0500): [SRX5308] [IKE] INFO: NAT not detected
Wed Nov 23 11:43:25 2016 (GMT -0500): [SRX5308] [IKE] INFO: NAT-D payload matches for 192.168.4.21[500]
Wed Nov 23 11:43:24 2016 (GMT -0500): [SRX5308] [IKE] INFO: For 192.168.4.21[500], Selected NAT-T version: RFC 3947
Wed Nov 23 11:43:25 2016 (GMT -0500): [SRX5308] [IKE] INFO: NAT-D payload matches for 93.225.201.7[500]
Wed Nov 23 11:43:24 2016 (GMT -0500): [SRX5308] [IKE] INFO: Received Vendor ID: DPD
Wed Nov 23 11:43:24 2016 (GMT -0500): [SRX5308] [IKE] INFO: Received Vendor ID: draft-ietf-ipsra-isakmp-xauth-06.txt
Wed Nov 23 11:43:24 2016 (GMT -0500): [SRX5308] [IKE] INFO: Received unknown Vendor ID
Wed Nov 23 11:43:24 2016 (GMT -0500): [SRX5308] [IKE] INFO: Received Vendor ID: draft-ietf-ipsec-nat-t-ike-02
Wed Nov 23 11:43:24 2016 (GMT -0500): [SRX5308] [IKE] INFO: Received unknown Vendor ID
Wed Nov 23 11:43:24 2016 (GMT -0500): [SRX5308] [IKE] INFO: Received Vendor ID: RFC 3947
Wed Nov 23 11:43:24 2016 (GMT -0500): [SRX5308] [IKE] INFO: Received unknown Vendor ID
Wed Nov 23 11:43:24 2016 (GMT -0500): [SRX5308] [IKE] INFO: Beginning Aggressive mode.
Wed Nov 23 11:43:24 2016 (GMT -0500): [SRX5308] [IKE] INFO: Received request for new phase 1 negotiation: 93.225.201.7[500]<=>192.168.4.21[500]
Wed Nov 23 11:43:24 2016 (GMT -0500): [SRX5308] [IKE] INFO: Remote configuration for identifier "remote.com" found
Perhaps attempting to test it from one VLAN to another is causing the problem, and a trip to Starbucks is in order?
The Documentation:
The Instructions:
The Screenshot from the Instructions:
'Tis an unusual paradox. One must enable Mode Config to enable the use of XAUTH & Edge Device options. But the directions clearly state, and show, that Mode Config is NOT to be enabled.
The Instructions:
The Screenshot from the Instructions:
There is no Policy Type 'Responder' from the dropdown list, but perhaps this is meant to be taken more generally (it is in the General section), since we are ultimately building a Responder IKE / VPN policy.
The Logger (newest first):
Thu Nov 24 18:07:36 2016 (GMT -0500): [SRX5308] [IKE] ERROR: Local configuration for 192.168.4.21[500] does not have mode config
Thu Nov 24 18:07:36 2016 (GMT -0500): [SRX5308] [IKE] ERROR: Local configuration for 192.168.4.21[500] does not have mode config
Thu Nov 24 18:07:36 2016 (GMT -0500): [SRX5308] [IKE] ERROR: Local configuration for 192.168.4.21[500] does not have mode config
Thu Nov 24 18:07:36 2016 (GMT -0500): [SRX5308] [IKE] ERROR: Local configuration for 192.168.4.21[500] does not have mode config
Thu Nov 24 18:07:36 2016 (GMT -0500): [SRX5308] [IKE] INFO: Received attribute type "ISAKMP_CFG_REQUEST" from 192.168.4.21[500]
Thu Nov 24 18:07:36 2016 (GMT -0500): [SRX5308] [IKE] INFO: XAuthUser RemoteVossnetUser Logged In from IP Address 192.168.4.21
Thu Nov 24 18:07:36 2016 (GMT -0500): [SRX5308] [IKE] INFO: Login succeeded for user "RemoteVossnetUser"
Thu Nov 24 18:07:36 2016 (GMT -0500): [SRX5308] [IKE] INFO: Received attribute type "ISAKMP_CFG_REPLY" from 192.168.4.21[500]
So, it appears that XAUTHUSER will work for authentication purposes without mode config, but then the tunnel collapses becauses it doesn't have a mode config.
Attempting to provide a Mode Config and make use of a VPN Policy results in this error message:
I am confused.
Hi lightknightrr,
Let me share this old forum link. Kindly read it and you may want to give it a try.
Regards,
DaneA
NETGEAR Community Team
My inner BOFH is stoked. I haven't used MSCHAP(v1 or v2) for anything in years (following the PPTP server instructions). Mind you, even with MSCHAPv2 authentication and MPPE-128 encryption, I've probably got about two weeks before that becomes a serious security concern ;-). But it works, right now, which is all that matters at the moment.
Hi lightknightrr,
I'm glad to know that it works! :)
Since it works, I encourage you to mark the appropriate reply as the “Accepted Solution” so others can be confident in benefiting from the solution. The NETGEAR Community looks forward to hearing from you and being a helpful resource in the future!
Regards,DaneA
NETGEAR Community Team
NETGEAR Academy
Boost your skills with the Netgear Academy - Get trained, certified and stay ahead with the latest Netgear technology!
Join Us!
