Thread Info
  • State Not Answered
  • Locked Locked
  • Replies 12 replies
  • Subscribers 1 subscriber
  • Views 2725 views
  • Users 0 members are here
Options
Suggested
This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

Sentinel SSH and ASL 3.201

Morten B.
Experiencing some probblems with connecting to th e asl-vpn with an sentinel-ssh client. I have followed the astaro mini-howto on this site, but there still is something thats wrong, and I cant figure it out  [:(] 

Jul  4 12:02:41 gw Pluto[26685]: "RoadWarrior_1" #1113: deleting state (STATE_MAIN_R3) 
Jul  4 12:02:41 gw Pluto[26685]: "RoadWarrior_1" #1112: deleting state (STATE_MAIN_R3) 
Jul  4 12:02:41 gw Pluto[26685]: "RoadWarrior_1" #1111: deleting state (STATE_MAIN_R3) 
Jul  4 12:02:41 gw Pluto[26685]: "RoadWarrior_1" #1110: deleting state (STATE_MAIN_R3) 
Jul  4 12:02:41 gw Pluto[26685]: "RoadWarrior_1" #1108: deleting state (STATE_MAIN_R3) 
Jul  4 12:02:41 gw Pluto[26685]: "RoadWarrior_1" #1106: deleting state (STATE_MAIN_R3) 
Jul  4 12:02:40 gw Pluto[26685]: packet from 193.71.91.198:500: ignoring Vendor ID payload 
Jul  4 12:02:40 gw Pluto[26685]: "RoadWarrior_1" 193.71.91.198 #1135: responding to Main Mode from unknown peer 193.71.91.198 
Jul  4 12:02:12 gw Pluto[26685]: "RoadWarrior_1" 193.71.91.198: deleting connection "RoadWarrior_1" instance with peer 193.71.91.198 
Jul  4 12:14:07 gw Pluto[26685]: packet from 193.71.91.198:500: ignoring Vendor ID payload
Jul  4 12:14:07 gw last message repeated 3 times
Jul  4 12:14:07 gw Pluto[26685]: "RoadWarrior_1" 193.71.91.198 #1147: responding to Main Mode from unknown peer 193.71.91.198
Jul  4 12:14:08 gw Pluto[26685]: "RoadWarrior_1" 193.71.91.198 #1147: ignoring informational payload, type IPSEC_INITIAL_CONTACT
Jul  4 12:14:08 gw Pluto[26685]: "RoadWarrior_1" 193.71.91.198 #1147: Peer ID is ID_USER_FQDN: 'morten@adcopartner.no'
Jul  4 12:14:08 gw Pluto[26685]: "RoadWarrior_1" 193.71.91.198 #1147: Issuer CRL not found
Jul  4 12:14:08 gw Pluto[26685]: "RoadWarrior_1" 193.71.91.198 #1147: Issuer CRL not found
Jul  4 12:14:08 gw Pluto[26685]: "RoadWarrior_1" 193.71.91.198 #1147: deleting connection "RoadWarrior_1" instance with peer 80.212.13.203
Jul  4 12:14:08 gw Pluto[26685]: "RoadWarrior_1" #1146: deleting state (STATE_MAIN_R3)
Jul  4 12:14:08 gw Pluto[26685]: "RoadWarrior_1" #1145: deleting state (STATE_MAIN_R3)
Jul  4 12:14:08 gw Pluto[26685]: "RoadWarrior_1" #1138: deleting state (STATE_MAIN_R3)
Jul  4 12:14:08 gw Pluto[26685]: "RoadWarrior_1" #1142: deleting state (STATE_MAIN_R3)
Jul  4 12:14:08 gw Pluto[26685]: "RoadWarrior_1" #1140: deleting state (STATE_MAIN_R3)
Jul  4 12:14:08 gw Pluto[26685]: "RoadWarrior_1" #1144: deleting state (STATE_MAIN_R3)
Jul  4 12:14:08 gw Pluto[26685]: "RoadWarrior_1" #1137: deleting state (STATE_MAIN_R3)
Jul  4 12:14:08 gw Pluto[26685]: "RoadWarrior_1" #1139: deleting state (STATE_MAIN_R3)
Jul  4 12:14:08 gw Pluto[26685]: "RoadWarrior_1" #1143: deleting state (STATE_MAIN_R3)
Jul  4 12:14:08 gw Pluto[26685]: "RoadWarrior_1" #1141: deleting state (STATE_MAIN_R3)
Jul  4 12:14:08 gw Pluto[26685]: "RoadWarrior_1" 193.71.91.198 #1147: sent MR3, ISAKMP SA established
Jul  4 12:14:08 gw Pluto[26685]: "RoadWarrior_1" 193.71.91.198 #1148: cannot respond to IPsec SA request because no connection is known for 192.168.11.0/24===213.236.255.226...193.71.91.198[morten@adcopartner.no]===192.168.11.1/32
Jul  4 12:14:09 gw Pluto[26685]: "RoadWarrior_1" 193.71.91.198 #1147: Quick Mode I1 message is unacceptable because it uses a previously used Message ID 0x884f1799 (perhaps this is a duplicated packet)
Jul  4 12:14:11 gw Pluto[26685]: "RoadWarrior_1" 193.71.91.198 #1147: Quick Mode I1 message is unacceptable because it uses a previously used Message ID 0x884f1799 (perhaps this is a duplicated packet)
Jul  4 12:14:15 gw Pluto[26685]: "RoadWarrior_1" 193.71.91.198 #1147: Quick Mode I1 message is unacceptable because it uses a previously used Message ID 0x884f1799 (perhaps this is a duplicated packet)

Any help appriciated as allways.


This thread was automatically locked due to age.
Parents
  • 0
    Can you please describe your settings on both systems, ASL and Sentinel?

    Thx Gert
  • 0 in reply to Gert Hansen
    asl:
    certificate-based authentication
    localnetwork: 192.168.10.0/255.255.255.0
    pptp-pool: 192.168.11.0/255.255.255.0
    roadwarrior access: from anywhere

    sentinel-ssh:
    downloaded signed certificate from asl as noted in the asl-post on setting up asl with ssh-sentinel.
    Remotenetwork: 192.168.11.0/255.255.255.0
    Same xxxx-lifetimes as ASL
    Same Encryption as ASL

    Does this help?
  • 0 in reply to Morten B.
    are u behind any kind of nat router...this makes a big difference..if so try and connect directly to the net and see if that fixs it
  • 0 in reply to asher
    Yes, in all our cases the rw's will be on a nat'ed network.

    How can we then solve this?
  • 0 in reply to Morten B.
    dude...as far as i can tell this is a major issue for me as well...nat simply messes things up!! 

    here read this from this site...
    http://www.samag.com/documents/s=4072/sam0203c/sam0203c.htm

    "Running a FreeS/WAN IPSec tunnel through any device with NAT (Network Address Translation) or IP masquerading will have unpredictable results and is not recommended. If the IPSec gateway is not itself the platform that performs NAT/masquerading (i.e., the tunnel terminates at the NAT gateway), then it is strongly recommended that the IPSec gateway lie in front of the NAT/masquerading platform. Essentially, IPSec must verify the packets before they are rewritten for NAT. The reason for this is that when NAT rewrites the IP headers of packets, the alteration causes the packets to fail IPSec’s integrity checks (Figures 1 and 2). Some attempts are being made to overcome this problem, including at least one IETF Internet Draft (http://search.ietf.org/internet-drafts/draft-aboba-nat-ipsec-04.txt) and RFC 2709."

    UCH!!

    this really blows...i too am searching for a reasonable way to get my remote users who sit behind a nat device to be able to connect to freeswan...I have read in some posts that some people have been able to do it? 

    Can anyone who has this working shed any more light on this issue?

    I think in the end this might be NAT device specific...today many of the NAT devices claim to support "IPSEC Passthru" technology...however these calims must be carefully examined...many times the passthorugh is only for very specific protocls like only des and no 3des etc...

    I am starting to formulate a picture about how this all works...if anyone out there has greater knowledge about this subject feel free to correct me about all this or simply chime in...

    asher
  • 0 in reply to asher
    here is the draft in case you want to read it the link in the article is wrong...

    http://search.ietf.org/internet-drafts/draft-ietf-ipsec-nat-t-ike-03.txt
  • 0 in reply to asher
    IPsec through NAT is not recommended, ok.. but I'm not quite sure what we are talking about exactly..

    You wanna have a vpn tunnel - ok. But how? You are talking about PPTP and IPsec... and within the IPsec you are talking about Roadwarrior (host-to-net) while you seem to have a standard connection (192.168.11.0/ 24===213.236.255.226...193.71.91.198[morten@adcopartner.no]===192.168.11.1/32)

    PPTP through NAT will work -if the NAT-machine supports PPTP-NATting- for one client.
  • 0 in reply to squeeze
    squeeze....we are talking about ipsec...specifcally roadwarrior

    for the most part YES pptp seems to work fine through most NAT devices...

    however ipsec does not?

    many of us need to connect remote roadwarrior users using ssh client to a astaro firewall

    most of the time these "roadwarriors" are sitting behind nat devices, which creates problems..this needs to be addressed and possibly fixed

    i hope i was clearer this time

    asher

     [:)]
  • 0 in reply to asher
    My roadwarriors are usually behind a nat'ed router.

    My ipsec-gateway is not behind nat'ed gateway, it is the nat gateway.
  • 0 in reply to Morten B.
    this is the response i got from dlink tech support...

    IPSEC Support:

    Firmware version upgrades will support Windows IPSEC implementation in the following configuration:

    Use only DES encryption in ESP mode with no encapsulation, no Integrity, in Tunnel mode and using a pre-shared key.

    hmm this doesnt look good for now...i am continuing my research for solutions to address this issue...but so far ipsec behind NAT doesnt really look to be viable...i hope they solve this soon...

    asher
  • 0 in reply to asher
    Well I just tried the SSH Sentinel behind a LinkSys BEFSR11 and a BEFVP41 with out success.  So I guess we can cross them off the list.

    I do know that the Cisco VPN client (VPN 3000 Concentrator Series) does work from behind these routers.

    I will send an email to SSH tech support to see if they have any idea of the differences (FreeS/WAN might be the issue from the above posts?)

    Just some additional infomation.
  • 0 in reply to mbeaver
    hmm.. there is quite a lengthy thread on this subject.

    as for the definition from PASSTHROUGH what every router supports is NOT what you are thinking.  It is nothing more than Port Forwarding.

    You have to have devices that support NAT-T which bypasses the NAT if you want to use SSH Sentinal from behind a NAT gateway.  According to SSH when an IPSEC/ESP Tunnel is built the Router bypasses the normal NAT function.

    To my knowledge only expensive Cisco an Nortel network componets have this feature.  I am sure there are others, however they wouldnt be cheap.

    RTFM.  Its very clearly defined in the SSH Documentation that IPSEC CANNOT be NATed.  Which of course is logical because then i dont have a Point to Point connection, which is a security hole and would eventually lead to Man in the Middle attacks and stealing sessions.
     
     [size="1"][ 08 July 2002, 03:49: Message edited by: Tmor ][/size]
Reply
  • 0 in reply to mbeaver
    hmm.. there is quite a lengthy thread on this subject.

    as for the definition from PASSTHROUGH what every router supports is NOT what you are thinking.  It is nothing more than Port Forwarding.

    You have to have devices that support NAT-T which bypasses the NAT if you want to use SSH Sentinal from behind a NAT gateway.  According to SSH when an IPSEC/ESP Tunnel is built the Router bypasses the normal NAT function.

    To my knowledge only expensive Cisco an Nortel network componets have this feature.  I am sure there are others, however they wouldnt be cheap.

    RTFM.  Its very clearly defined in the SSH Documentation that IPSEC CANNOT be NATed.  Which of course is logical because then i dont have a Point to Point connection, which is a security hole and would eventually lead to Man in the Middle attacks and stealing sessions.
     
     [size="1"][ 08 July 2002, 03:49: Message edited by: Tmor ][/size]
Children
No Data