Thread Info
  • State Not Answered
  • Locked Locked
  • Replies 15 replies
  • Subscribers 1 subscriber
  • Views 2337 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

ssh sentinel roadwarrior problems since v5 update

MatthiasFleschuetz
dear list,

after our v5-update the ssh-sentinel clients connections dont work anymore.
After couldnt debugging this, i deleted all the existing certificates and settings, now I followed the official AstaroV5-HowTo for IPSEC Roadwarriors with SSH Sentinel, but I cant get it working again.

I allways get "INVALID_ID_INFORMATION" as the reason of error.
The Astaro-Log says that there is no connection, but the connection is defined the right way:

vpn-ipsec_roadwarriors
Conn. Key(s):  Matthias_Eichler
Local Endpoint:   transit_eth3
Remote Endpoint:   Any
Local Subnet:  lan_eth5 (Network)
Remote Subnet:  none
IPSec Policy:  AES_PFS

The Astaro VPN Status shows:
000 "D_vpn-ipsec__roadwarriors_0": 10.1.0.0/16===82.135.32.2...%virtual[m.eichler@kernzeit.com]
000 "D_vpn-ipsec__roadwarriors_0":   CAs: 'C=de, ST=Bavaria, L=Ottobrunn, O=kernzeit AG, OU=Technik, CN=ca, E=ca@kernzeit.com'...'%any'
000 "D_vpn-ipsec__roadwarriors_0":   ike_life: 7800s; ipsec_life: 3600s; rekey_margin: 540s; rekey_fuzz: 100%; keyingtries: 0
000 "D_vpn-ipsec__roadwarriors_0":   policy: RSASIG+ENCRYPT+TUNNEL+PFS; interface: eth3; unrouted
000 "D_vpn-ipsec__roadwarriors_0":   newest ISAKMP SA: #0; newest IPsec SA: #0; eroute owner: #0
000 "D_vpn-ipsec__roadwarriors_0":   IKE algorithms wanted: 5_000-1-5, flags=-strict
000 "D_vpn-ipsec__roadwarriors_0":   IKE algorithms found:  5_192-1_128-5, 
000 "D_vpn-ipsec__roadwarriors_0":   ESP algorithms wanted: 12_128-1, ; pfsgroup=5; flags=-strict
000 "D_vpn-ipsec__roadwarriors_0":   ESP algorithms loaded: 12_128-1_128,

But the SSH Sentinel stops on Phase-2 with "Exchanging IPSec proposals FAILED!

The SSH Sentinel Audit says:
: Phase-2 [initiator] for ipv4(icmp:0,[0..3]=10.99.0.31) and ipv4(icmp:0,[0..3]=82.135.32.2) failed; Aborted notification.
: The remote server at 82.135.32.2:500 is 'draft-ietf-ipsec-nat-t-ike-03'
DEBUG: 0.0.0.0:500 (Initiator)  82.135.32.2:4500 { d4c463db e676f79c - 80685c65 7885e5ec [-1] / 0x00000000 } IP; MESSAGE: Phase 1 version = 1.0, auth_method = RSA signatures, cipher = 3des-cbc, hash = md5, prf = hmac-md5, life = 0 kB / 7800 sec, key len = 0, group = 5
DEBUG: 0.0.0.0:4500 (Responder)  82.135.32.2:4500 { d4c463db e676f79c - 80685c65 7885e5ec [1] / 0x403fb14d } Info; Received notify err = Invalid ID information (18) to isakmp sa, delete it

And the Astaro Log tells:
2004:08:03-16:15:35 (none) pluto[23329]: packet from 217.232.209.131:500: SSH Sentinel 1.4.1 found, setting XAUTH_ACK quirk
2004:08:03-16:15:35 (none) pluto[23329]: packet from 217.232.209.131:500: received Vendor ID payload [SSH Sentinel 1.4.1]
2004:08:03-16:15:35 (none) pluto[23329]: packet from 217.232.209.131:500: ignoring Vendor ID payload [draft-stenberg-ipsec-nat-traversal-02]
2004:08:03-16:15:35 (none) pluto[23329]: packet from 217.232.209.131:500: ignoring Vendor ID payload [draft-stenberg-ipsec-nat-traversal-01]
2004:08:03-16:15:35 (none) pluto[23329]: packet from 217.232.209.131:500: received Vendor ID payload [draft-ietf-ipsec-nat-t-ike-03]
2004:08:03-16:15:35 (none) pluto[23329]: packet from 217.232.209.131:500: ignoring Vendor ID payload [draft-ietf-ipsec-nat-t-ike-02_n]
2004:08:03-16:15:35 (none) pluto[23329]: packet from 217.232.209.131:500: ignoring Vendor ID payload [draft-ietf-ipsec-nat-t-ike-02]
2004:08:03-16:15:35 (none) pluto[23329]: packet from 217.232.209.131:500: ignoring Vendor ID payload [draft-ietf-ipsec-nat-t-ike-00]
2004:08:03-16:15:35 (none) pluto[23329]: packet from 217.232.209.131:500: ignoring Vendor ID payload [XAUTH]
2004:08:03-16:15:35 (none) pluto[23329]: "D_vpn-ipsec__roadwarriors_0"[2] 217.232.209.131 #4: responding to Main Mode from unknown peer 217.232.209.131
2004:08:03-16:15:35 (none) pluto[23329]: "D_vpn-ipsec__roadwarriors_0"[2] 217.232.209.131 #4: transition from state (null) to state STATE_MAIN_R1
2004:08:03-16:15:35 (none) pluto[23329]: "D_vpn-ipsec__roadwarriors_0"[2] 217.232.209.131 #4: NAT-Traversal: Result using draft-ietf-ipsec-nat-t-ike-02/03: peer is NATed
2004:08:03-16:15:35 (none) pluto[23329]: "D_vpn-ipsec__roadwarriors_0"[2] 217.232.209.131 #4: transition from state STATE_MAIN_R1 to state STATE_MAIN_R2
2004:08:03-16:15:35 (none) pluto[23329]: "D_vpn-ipsec__roadwarriors_0"[2] 217.232.209.131 #4: ignoring informational payload, type IPSEC_INITIAL_CONTACT
2004:08:03-16:15:35 (none) pluto[23329]: "D_vpn-ipsec__roadwarriors_0"[2] 217.232.209.131 #4: Main mode peer ID is ID_USER_FQDN: 'm.eichler@kernzeit.com'
2004:08:03-16:15:35 (none) pluto[23329]: "D_vpn-ipsec__roadwarriors_0"[2] 217.232.209.131 #4: Issuer CRL not found
2004:08:03-16:15:35 (none) pluto[23329]: "D_vpn-ipsec__roadwarriors_0"[2] 217.232.209.131 #4: Issuer CRL not found
2004:08:03-16:15:35 (none) pluto[23329]: "D_vpn-ipsec__roadwarriors_0"[2] 217.232.209.131 #4: transition from state STATE_MAIN_R2 to state STATE_MAIN_R3
2004:08:03-16:15:35 (none) pluto[23329]: | NAT-T: new mapping 217.232.209.131:500/4500)
2004:08:03-16:15:35 (none) pluto[23329]: "D_vpn-ipsec__roadwarriors_0"[2] 217.232.209.131:4500 #4: sent MR3, ISAKMP SA established
2004:08:03-16:15:35 (none) pluto[23329]: "D_vpn-ipsec__roadwarriors_0"[2] 217.232.209.131:4500 #4: Virtual IP 10.99.0.31/32 is already used by '(none)'
2004:08:03-16:15:35 (none) pluto[23329]: "D_vpn-ipsec__roadwarriors_0"[2] 217.232.209.131:4500 #4: Your ID is 'm.eichler@kernzeit.com'
2004:08:03-16:15:35 (none) pluto[23329]: "D_vpn-ipsec__roadwarriors_0"[2] 217.232.209.131:4500 #4: Virtual IP 10.99.0.31/32 is already used by '(none)'
2004:08:03-16:15:35 (none) pluto[23329]: "D_vpn-ipsec__roadwarriors_0"[2] 217.232.209.131:4500 #4: Your ID is 'm.eichler@kernzeit.com'
2004:08:03-16:15:35 (none) pluto[23329]: "D_vpn-ipsec__roadwarriors_0"[2] 217.232.209.131:4500 #4: cannot respond to IPsec SA request because no connection is known for 10.1.0.0/16===82.135.32.2:4500...217.232.209.131:4500[m.eichler@kernzeit.com]===10.99.0.31/32
2004:08:03-16:15:35 (none) pluto[23329]: "D_vpn-ipsec__roadwarriors_0"[2] 217.232.209.131:4500 #4: sending encrypted notification INVALID_ID_INFORMATION to 217.232.209.131:4500


Thanks for all your help!!!

Matthias


This thread was automatically locked due to age.
Parents
  • 0
    Hi,

    two messages are important (ignore all others like ID payload, ...)

    2004:08:03-16:15:35 (none) pluto[23329]: "D_vpn-ipsec__roadwarriors_0"[2] 217.232.209.131:4500 #4: Virtual IP 10.99.0.31/32 is already used by '(none)'

    There seems to be an error with virtual IP is it already in use somewhere?

    2004:08:03-16:15:35 (none) pluto[23329]: "D_vpn-ipsec__roadwarriors_0"[2] 217.232.209.131:4500 #4: cannot respond to IPsec SA request because no connection is known for 10.1.0.0/16===82.135.32.2:4500...217.232.209.131:4500[m.eichler@kernzeit.com]===10.99.0.31/32

    Please check if the subnet definitions are correct on ASL and VPN client. But maybe the second error is just a consequence of the first error.

    Xeno
  • 0 in reply to Xeno
    How can I find where the virt. IP is already in use?!?!?!?

    Now I seperated PPTP-Pool, IPsec-Pool and also the virt. IPs for SSH Sentinel connections into three different networks (PPTP: 10.0.31.0/24, L2TP: 10.98.0.0/24, virt.IPs: 10.99.0.0/24).
    I also restarted also the whole IPsec section, but the log still says:

    ---cut---
    2004:08:04-12:36:07 (none) pluto[2996]: "D_vpn-ipsec__roadwarriors_0"[1] 217.232.218.198:4500 #3: sent MR3, ISAKMP SA established
    2004:08:04-12:36:07 (none) pluto[2996]: "D_vpn-ipsec__roadwarriors_0"[1] 217.232.218.198:4500 #3: Virtual IP 10.99.0.31/32 is already used by '(none)'
    2004:08:04-12:36:07 (none) pluto[2996]: "D_vpn-ipsec__roadwarriors_0"[1] 217.232.218.198:4500 #3: Your ID is 'm.eichler@kernzeit.com'
    2004:08:04-12:36:07 (none) pluto[2996]: "D_vpn-ipsec__roadwarriors_0"[1] 217.232.218.198:4500 #3: Virtual IP 10.99.0.31/32 is already used by '(none)'
    2004:08:04-12:36:07 (none) pluto[2996]: "D_vpn-ipsec__roadwarriors_0"[1] 217.232.218.198:4500 #3: Your ID is 'm.eichler@kernzeit.com'
    2004:08:04-12:36:07 (none) pluto[2996]: "D_vpn-ipsec__roadwarriors_0"[1] 217.232.218.198:4500 #3: cannot respond to IPsec SA request because no connection is known for 10.1.0.0/16===82.135.32.2:4500...217.232.218.198:4500[m.eichler@kernzeit.com]===10.99.0.31/32
    2004:08:04-12:36:07 (none) pluto[2996]: "D_vpn-ipsec__roadwarriors_0"[1] 217.232.218.198:4500 #3: sending encrypted notification INVALID_ID_INFORMATION to 217.232.218.198:4500
    ---cut---

    So how do I get where is IP is in use, although it cant be already in use...

    Thanks for your help!

    Matthias
  • 0 in reply to MatthiasFleschuetz
    Ok, I could find out that the Astaro marks the virt. IP in use although the connections wasnt succesful.
    I could figure this out because whith each try there is one more entry of "Virtual IP 10.99.0.31/32 is already used by '(none)'".
    So for me this is more a bug than a feature, escpecially because I cant remove these entries!

    I also saw a difference between the Sentinel config (as told in the howto) for the virtual IP is IP-adress/24. In all Astaro logs it seems to be IP-adress/32. Does this make sense?

    Matthias
Reply
  • 0 in reply to MatthiasFleschuetz
    Ok, I could find out that the Astaro marks the virt. IP in use although the connections wasnt succesful.
    I could figure this out because whith each try there is one more entry of "Virtual IP 10.99.0.31/32 is already used by '(none)'".
    So for me this is more a bug than a feature, escpecially because I cant remove these entries!

    I also saw a difference between the Sentinel config (as told in the howto) for the virtual IP is IP-adress/24. In all Astaro logs it seems to be IP-adress/32. Does this make sense?

    Matthias
Children
  • 0 in reply to MatthiasFleschuetz
    Do you use PSK for your L2TP users? If yes, then this is the reason why it fails. Currently Openswan does not support both X.509 IPSec roadwarriors and PSK L2TP roadwarriors at the same time. This is a bug in Openswan, which has not been resolved yet.

    Regards,
    Stephan
  • 0 in reply to Stephan_Scholz
    [ QUOTE ]
    Do you use PSK for your L2TP users? If yes, then this is the reason why it fails. Currently Openswan does not support both X.509 IPSec roadwarriors and PSK L2TP roadwarriors at the same time. This is a bug in Openswan, which has not been resolved yet.


    [/ QUOTE ]

    Sorry, I dont get it:
    Openswan does not support IPsec Roadwarrior Connections (SSH  sentinel) and L2TP over IPsec not at the same time?
    But how may I use L2TP without PSK on a Astaro?!?

    Because it seems that we need both at the same time:
    we have l2tp over ipsec users because of the user authentification possible with this feature and because of the simplicity and because of the SSH sentinel does not coorporate well with our AntiVirus solution...:-(
    But we also need ssh sentinel for some homeoffices, because people there have win2k and win2k doesnt work with psk l2tp...

    Matthias
  • 0 in reply to MatthiasFleschuetz
    Ok, I just deactivated the MS L2TP connection and it worked immediately...

    So, maybe somebody can answer me:
    - how to implement win l2tp clients (maybe not with psk?!?)
    and ssh sentinel clients on the same time?!??!?

    There is no howto or documentation about this to find...

    Thanks,

    Matthias
  • 0 in reply to MatthiasFleschuetz
    Actually the problem is on a more general level, my previous post may be misleading.
    The problem lies within Openswan and virtual IP addresses. After enabling an L2TP connection, you are not able to use "normal" virtual IP addresses anymore. This means that you are not able to use normal IPSec roadwarriors, because in general they would use virtual IP addresses.
    This is a current limitation of Openswan. A fix for this problem is in preparation, but will require some more testing and time before it is being released.

    Regards,
    Stephan
  • 0 in reply to Stephan_Scholz
    Ok, thats more clear for me now...although I dont like the content of the  answer because it gives me some biiiig problem...:-(

    Does anybody knows something about the timeframe for the solution? Just about:
    [   ] some week(s)
    [   ] some months
    [   ] dont have a clue...;-)

    Thanks,

    Matthias
  • 0 in reply to MatthiasFleschuetz
    Unfortunately I cannot give you an exact date when this will be solved. However, it's high on the priority list. So I would expect it to be included in one of the next Up2Dates.

    Regards,
    Stephan
  • 0 in reply to Stephan_Scholz
    [ QUOTE ]
    Unfortunately I cannot give you an exact date when this will be solved. However, it's high on the priority list. So I would expect it to be included in one of the next Up2Dates.

    [/ QUOTE ]
    Oooh well, that sounds fine for me ;-) Will put this topic a bit lower in my prioritylis..:-)

    Thanks a lot,

    Matthias
  • 0 in reply to Stephan_Scholz
    [ QUOTE ]
    Unfortunately I cannot give you an exact date when this will be solved. However, it's high on the priority list. So I would expect it to be included in one of the next Up2Dates.


    [/ QUOTE ]

    I just wanted to monitor your known issue list to see when the bug will be solved, but I couldnt find the bug in the list.
    Can you maybe tell me the bug ID so that I can monitor the up2date-packages especially for this bug?!?

    Thanks
  • 0 in reply to MatthiasFleschuetz
    The ID of this issue is 1442.

    Regards,
    Stephan
  • 0 in reply to Stephan_Scholz
    for everyone...since the latest Up2Date package to version 5.026 the bug is fixed...thats what the readme says, but untestet yet...
Cookie Information Banner