Welcome, Guest. Please login or register.
Did you miss your activation email?
Saturday 09 November 2024, 12:20:32 pm

Login with username, password and session length

CLICK HERE for the The official Endian Roadmap and Issue tracker
14250 Posts in 4377 Topics by 6515 Members
Latest Member: hulteends
Search:     Advanced search
+  EFW Support
|-+  Support
| |-+  VPN Support
| | |-+  2.5.1 IPSEC tunnels cannot use FQDN DYNDNS
0 Members and 1 Guest are viewing this topic. « previous next »
Pages: [1] Go Down Print
Author Topic: 2.5.1 IPSEC tunnels cannot use FQDN DYNDNS  (Read 28742 times)
mudgie
Jr. Member
*
Offline Offline

Posts: 1


« on: Thursday 16 February 2012, 11:42:54 am »

I'm new to the EFW (love it) but have one issue that I can't figure out. I have IPSEC tunnels up and running with SonicWALLs and other EFW's, but cannot establish a tunnel using a hostname. They work fine with the IP, but my peer will eventually renew and that'll be the end of the tunnel until I intervene again. I have OpenDNS servers in the red interface and everything seems to update normally. Only the IPSEC tunnels fail to resolve the peer. Any ideas?
Logged
jcasares
Jr. Member
*
Offline Offline

Posts: 9


« Reply #1 on: Saturday 18 February 2012, 03:54:37 am »

It worked with 2.4.1 but when we moved to 2.5.1 our tunnel that uses a name stopped working. So it might be another bug from 2.5.1 that seems to be quite buggy if you tell me.
Logged
ruhllatio
Full Member
***
Offline Offline

Posts: 10


« Reply #2 on: Sunday 19 February 2012, 07:09:30 am »

Gents,

Have you tried configuring the Local and Remote IDs with what you expect to respond?  Most IPSec tunnels have to authenticate their IKE session with an identity string.  By default, most endpoints will try to identify themselves as their IP Address.  Since you know using IP Addresses for the tunnel endpoints work, this logic is sound as the connection succeeds.  If you try to configure the identities with their respective hostnames on both ends (if that is what you have your Pre-Shared Key mapped to) this may help override the default verification.  I'm guessing you're using some kind of DDNS.  Unfortuantely, PTR records are generally not available through these services so doing a reverse lookup of your external IP will usually yield a different hostname (likely auto-generated by your ISPs DNS service).  Thus, IKE main mode will fail if it requires identity verification.  Try enabling additional debug logging for pluto (can be done in the GUI) and post up your results with the hostname connection failing.  I currently don't have a way to test as I do not use IPSec VPN on my endi.

Chris
Logged
jcasares
Jr. Member
*
Offline Offline

Posts: 9


« Reply #3 on: Sunday 19 February 2012, 09:06:58 am »

You might have missed that I said the same tunnel was working with 2.4.1 (just restored the configuration, and also tried recreating it).
So it isn't configuration from our part but a change in the new Endian version, namely a BUG.
Logged
ruhllatio
Full Member
***
Offline Offline

Posts: 10


« Reply #4 on: Sunday 19 February 2012, 10:18:04 am »

Something not working the same exact way isn't necessarily a bug.  In this industry, it can be called expanded features.  Just saying it's a bug and not providing any relevant information other than "it worked before, fix it" is counterproductive.  I'm not familiar with 2.4.1 or what kind of configuration it offered for IPSec tunnels.  I just started using Endian at 2.5.1.  Pardon my ignorance.  I was simply trying to help.  Still, could you post a sample from your IPSec log?  I wanted to join this community with the intention of offering solutions to other users, and short of surmising what might be the problem I can't do much without some insight to what is happening.  Replicating the issue isn't an option for me as I don't have anyone to peer with.  So, help me help you.  I'm Cisco and Brocade certified.  Know the ins and outs of VPN.  Been a network engineer for 8 years.  I think I can help with some log output.

Thanks.

Chris
Logged
eighty2scrambler
Full Member
***
Offline Offline

Posts: 11


« Reply #5 on: Tuesday 01 May 2012, 02:03:07 am »

After posting a similar complaint today on the forums I stubmled across this post.  I wouldn't be following proper etiquette if I didn't post my findings.

I too was having an issue with EFW 2.4.1 talking to EFW 2.5.1 over IPSEC tunnel using hostname (created by dyndns.org)  I have one site that has a static IP and the other which is dynamic.  All was well with the respective IP's in the hostname field.  When I changd the IP to a hostname I could establish connection. Chcked logs and found INVALID ID INFO. 
After finding this post, I changed the LocalID and RemoteID to the hostnames of that particular site. Clicked save, and no more erros. Connection established.

So to your repsonse, your knowledge of VPN inside and out did provide assistance to one lonely IT guy out there who does look at these forums, and to that.. I say THank you! Smiley

 Grin
Logged
dda
Sr. Member
****
Offline Offline

Posts: 227


« Reply #6 on: Wednesday 15 August 2012, 05:30:17 am »

I am sorry but could you clarify this a little more I dont quite follow.  Is the correct servername.ddns-example.com is the local id on the server and the remote id on the client and clientname.ddnsexample.com is the local id on the client on the remote id in the user on the server?
Logged
dda
Sr. Member
****
Offline Offline

Posts: 227


« Reply #7 on: Wednesday 15 August 2012, 05:32:56 am »

further on one side I don't have a static address.
Logged
Pages: [1] Go Up Print 
« previous next »
Jump to:  

Page created in 0.063 seconds with 20 queries.
Powered by SMF 1.1 RC2 | SMF © 2001-2005, Lewis Media Design by 7dana.com