ultimoblaze

Forum Replies Created

Viewing 7 posts - 1 through 7 (of 7 total)
  • Author
    Posts
  • in reply to: VPN with AD authentication #53914
    ultimoblaze
    Member

    Here is some more information. First are my realm setup and cross authentication setup. Then my VPN setup and then the VPN log when trying to login.



    15:47:38 	Re-using SSL/TLS context
    15:47:38 LZO compression initialized
    15:47:38 TCP connection established with 24.33.70.89:56504
    15:47:38 TCPv4_SERVER link local: [undef]
    15:47:38 TCPv4_SERVER link remote: 24.33.70.89:56504
    15:47:40 24.33.70.89:56504 [administrator@SLI.COM] Trying Kerberos 5 (Trusted KDC) authentication
    15:47:40 24.33.70.89:56504 [administrator@SLI.COM] Kerberos 5 authentication failed: host/zeroshell.sli.lan@SLI.LAN: Server not found in Kerberos database while getting credentials
    15:47:40 24.33.70.89:56504 WARNING: Failed running command (--auth-user-pass-verify): external program exited with error status: 11
    15:47:40 24.33.70.89:56504 TLS Auth Error: Auth Username/Password verification failed for peer

    Does anybody have any suggestions?

    Thanks,
    Ultimoblaze

    in reply to: VPN with AD authentication #53913
    ultimoblaze
    Member

    I found out I need to create a trust relationship on the AD side. I did this and entered the same password as on the Zeroshell machine. I still cannot get it to authenticate against the AD though. Has anybody done this successfully?

    Thanks,
    Ultimoblaze

    in reply to: VPN with AD authentication #53912
    ultimoblaze
    Member

    I’ve gotten the DNS forwarding to work. That wasn’t as difficult to figure out. I’m a novice though at authentication protocols. I don’t understand how to get the cross authentication to work.

    My configuration is as follows. The Zeroshell box has the K5 realm as ABC.com. It’s hostname is zeroshell. the LDAP base is dc=ABC,dc=com. I don’t understand what each of these do, other than hostname. My AD domain is ABC.com and the AD controller is server1.ABC.com.

    Given this information, how can I have the zeroshell box accept openVPN connections authenticated against the AD accounts? Is there something I have to do on the AD controller side?

    Thanks,
    Ultimoblaze

    in reply to: Possible DHCP issue? #53879
    ultimoblaze
    Member

    So I’ve turned off the DHCP server in Zeroshell and used this forum post https://www.zeroshell.org/forum/viewtopic.php?t=557 to set up dhcrelay to a DHCP server running on Windows 2008. Unfortunately, all of my clients get IP addresses from the same subnet. The startup script looks like this:

    dhcrelay -i ETH01.1 -i ETH01.10 -i ETH01.20 192.168.101.5

    All of my clients get IP addresses as if they were on VLAN 10. This might fix my issues with the DHCP server, but now my VLANs are all using the same subnet.

    Does anybody have any suggestions?

    Thanks,
    Ultimoblaze

    in reply to: Possible DHCP issue? #53878
    ultimoblaze
    Member

    I have some more log data. Something must be going wrong, but I don’t know nearly enough about how DHCP works to try and fix it.

    Here is a small portion of the log from yesterday. The log is filled with pages and pages of INFORMs and ACKs and DISCOVERs.

    09:19:22 DHCPDISCOVER from 48:ee:0c:87:d3:97 (investment-PC) via ETH01.10
    09:19:22 DHCPOFFER on 192.168.110.112 to 48:ee:0c:87:d3:97 (investment-PC) via ETH01.10
    09:19:22 DHCPDISCOVER from 48:ee:0c:87:d3:97 (investment-PC) via ETH01.10
    09:19:22 DHCPOFFER on 192.168.110.112 to 48:ee:0c:87:d3:97 (investment-PC) via ETH01.10
    09:19:22 DHCPDISCOVER from 48:ee:0c:87:d3:97 (investment-PC) via ETH01.10
    09:19:22 DHCPOFFER on 192.168.110.112 to 48:ee:0c:87:d3:97 (investment-PC) via ETH01.10
    09:19:22 DHCPDISCOVER from 48:ee:0c:87:d3:97 (investment-PC) via ETH01.10
    09:19:22 DHCPOFFER on 192.168.110.112 to 48:ee:0c:87:d3:97 (investment-PC) via ETH01.10
    09:19:22 DHCPDISCOVER from 48:ee:0c:87:d3:97 (investment-PC) via ETH01.10
    09:19:22 DHCPOFFER on 192.168.110.112 to 48:ee:0c:87:d3:97 (investment-PC) via ETH01.10
    09:19:22 DHCPDISCOVER from 48:ee:0c:87:d3:97 (investment-PC) via ETH01.10
    09:19:22 DHCPOFFER on 192.168.110.112 to 48:ee:0c:87:d3:97 (investment-PC) via ETH01.10
    09:19:22 DHCPDISCOVER from 48:ee:0c:87:d3:97 (investment-PC) via ETH01.10
    09:19:22 DHCPOFFER on 192.168.110.112 to 48:ee:0c:87:d3:97 (investment-PC) via ETH01.10

    Any suggestions?

    Thanks,
    Ultimoblaze

    in reply to: l2tp/Ipsec VPN Help #53870
    ultimoblaze
    Member

    I’ve been working on this some more and was able to rule out the firewall. I disabled the firewall on my Windows 7 machine and set the policies to accept on Zeroshell. I have been able to contact the Zeroshell machine, but receive a handful of failures and rejections in the Zeroshell log.

    What I’ve tried:

    Windows 7 VPN Security setting: Automatic
    admin username and password
    Zeroshell log:

    20:46:55 	INFO: respond new phase 1 negotiation: xx.xx.172.2[500]<=>xx.xx.70.89[500]
    20:46:55 INFO: begin Identity Protection mode.
    20:46:55 INFO: received broken Microsoft ID: MS NT5 ISAKMPOAKLEY
    20:46:55 INFO: received Vendor ID: RFC 3947
    20:46:55 INFO: received Vendor ID: draft-ietf-ipsec-nat-t-ike-02
    20:46:55 INFO: received Vendor ID: FRAGMENTATION
    20:46:55 INFO: Selected NAT-T version: RFC 3947
    20:46:55 ERROR: invalid DH group 20.
    20:46:55 ERROR: invalid DH group 19.
    20:46:55 ERROR: rejected enctype: DB(prop#1:trns#1):Peer(prop#1:trns#3) = 3DES-CBC:7
    20:46:55 ERROR: rejected hashtype: DB(prop#1:trns#1):Peer(prop#1:trns#3) = MD5:SHA
    20:46:55 ERROR: rejected dh_group: DB(prop#1:trns#1):Peer(prop#1:trns#3) = 1024-bit MODP group:2048-bit MODP group
    20:46:55 ERROR: rejected hashtype: DB(prop#1:trns#1):Peer(prop#1:trns#4) = MD5:SHA
    20:46:55 ERROR: rejected dh_group: DB(prop#1:trns#1):Peer(prop#1:trns#4) = 1024-bit MODP group:2048-bit MODP group
    20:46:55 ERROR: rejected hashtype: DB(prop#1:trns#1):Peer(prop#1:trns#5) = MD5:SHA
    20:46:55 ERROR: no suitable proposal found.
    20:46:55 ERROR: failed to get valid proposal.
    20:46:55 ERROR: failed to process packet.

    I tried forcing the security setting to L2TP/IPsec and received the same results.

    Can anybody provide some help in this matter?

    Thanks,
    Ultimoblaze

    in reply to: Connection overload #52994
    ultimoblaze
    Member

    So I couldn’t figure it out and decided to do the update to RC3 and it seems to have fixed the problem. I don’t know why the RC2 suddenly started having this issue, but it has been fine the last day now. If it happens again I’ll be back to post.

Viewing 7 posts - 1 through 7 (of 7 total)