Hi guys,
I have tried removing the ns-cert-type from the nm-openvpn-service.c file.
Thus I have successfully connected to my openvpn server using x509
authentication. However I am facing another issue now: routes are not
pushed, or if they are, they are ignored Here is the log:
May 30 11:10:47 mitsos nm-openvpn[3319]: LZO compression initialized
May 30 11:10:47 mitsos nm-openvpn[3319]: Attempting to establish TCP connection
with 1.2.3.4:443 [nonblock]
May 30 11:10:48 mitsos nm-openvpn[3319]: TCP connection established with
1.2.3.4:443
May 30 11:10:48 mitsos nm-openvpn[3319]: TCPv4_CLIENT link local: [undef]
May 30 11:10:48 mitsos nm-openvpn[3319]: TCPv4_CLIENT link remote: 1.2.3.4:443
May 30 11:10:50 mitsos nm-openvpn[3319]: WARNING: 'dev-type' is used
inconsistently, local='dev-type tun', remote='dev-type tap'
May 30 11:10:50 mitsos nm-openvpn[3319]: WARNING: 'link-mtu' is used
inconsistently, local='link-mtu 1544', remote='link-mtu 1576'
May 30 11:10:50 mitsos nm-openvpn[3319]: WARNING: 'tun-mtu' is used
inconsistently, local='tun-mtu 1500', remote='tun-mtu 1532'
May 30 11:10:50 mitsos nm-openvpn[3319]: [server.physics.auth.gr] Peer
Connection Initiated with 1.2.3.4:443
May 30 11:10:51 mitsos nm-openvpn[3319]: WARNING: Since you are using --dev tun
with a point-to-point topology, the second argument to --ifconfig must be an IP
address. You are using something (255.255.255.0) that looks more like a
netmask. (silence this warning with --ifconfig-nowarn)
May 30 11:10:51 mitsos kernel: tun0: Disabled Privacy Extensions
May 30 11:10:51 mitsos nm-openvpn[3319]: TUN/TAP device tun0 opened
May 30 11:10:51 mitsos nm-openvpn[3319]: /sbin/ip link set dev tun0 up mtu 1500
May 30 11:10:51 mitsos nm-openvpn[3319]: /sbin/ip addr add dev tun0 local
192.168.1.1 peer 255.255.255.0
May 30 11:10:51 mitsos nm-openvpn[3319]:
/usr/bin/nm-openvpn-service-openvpn-helper tun0 1500 1544 192.168.1.1
255.255.255.0 init
May 30 11:10:51 mitsos NetworkManager: <info> VPN connection
'server.physics.auth.gr' (IP Config Get) reply received.
May 30 11:10:51 mitsos NetworkManager: <info> VPN Gateway: 1.2.3.4
May 30 11:10:51 mitsos NetworkManager: <info> Tunnel Device: tun0
May 30 11:10:51 mitsos NetworkManager: <info> Internal IP4 Address: 192.168.1.1
May 30 11:10:51 mitsos NetworkManager: <info> Internal IP4 Netmask:
255.255.255.0
May 30 11:10:51 mitsos NetworkManager: <info> Internal IP4 Point-to-Point
Address: 255.255.255.0
May 30 11:10:51 mitsos NetworkManager: <info> Maximum Segment Size (MSS): 0
May 30 11:10:51 mitsos NetworkManager: <info> Internal IP4 DNS: 192.168.1.2
May 30 11:10:51 mitsos NetworkManager: <info> DNS Domain: '(none)'
May 30 11:10:51 mitsos NetworkManager: <info> Login Banner:
May 30 11:10:51 mitsos NetworkManager: <info>
-----------------------------------------
May 30 11:10:51 mitsos NetworkManager: <info> (null)
May 30 11:10:51 mitsos NetworkManager: <info>
-----------------------------------------
May 30 11:10:51 mitsos nm-openvpn[3319]: Initialization Sequence Completed
May 30 11:10:52 mitsos NetworkManager: <info> VPN connection
'server.physics.auth.gr' (IP Config Get) complete.
May 30 11:10:52 mitsos NetworkManager: <info> VPN plugin state changed: 4
Cheers,
On Fri, 23 May 2008, Dan Williams wrote:
> On Fri, 2008-05-23 at 14:00 -0500, Casey Harkins wrote:
>> On Fri, 2008-05-23 at 07:57 +0300, Dimitris Zilaskos wrote:
>>> On Thu, 22 May 2008, Dan Williams wrote:
>>>> I didn't originally write that bit, but what's the impact of getting rid
>>>> of the check, if any? That openvpn will just accept any old certificate
>>>> that it gets sent from the server?
>>>>
>>>> Dan
>>>
>>>
>>> No, this check examines if the certificate has the nsCertType field set to
>>> "client", it has nothing to do with certificate age. As I mentioned in my
>>> previous mail, it is an old depracated field. It has been replaced by
>>> extendedkeyusage (http://www.ietf.org/rfc/rfc3280.txt?number=3280).
>>>
>>
>> Also worth noting that it has nothing to do with validating the
>> certificate.
>>
>> The question is should it be removed entirely or made a preference in
>> nm-openvpn-properties? Removing is as simple as removing the relevant
>> lines (as indicated in the thread referenced earlier). Making it a
>> preference should be relatively straight forward as well. I'd imagine a
>> patch would be the best way to make this happen. If there aren't any
>> takers, I'll whip one up next week to make the ns-cert-type openvpn
>> option configurable (none, client, server).
>
> A patch to just remove the check entirely would be fine with me. It
> doesn't sound like we need it at all.
>
> Dan
>
--
============================================================================
Dimitris Zilaskos
Department of Physics @ Aristotle University of Thessaloniki , Greece
PGP key : http://tassadar.physics.auth.gr/~dzila/pgp_public_key.asc
http://egnatia.ee.auth.gr/~dzila/pgp_public_key.asc
MD5sum : de2bd8f73d545f0e4caf3096894ad83f pgp_public_key.asc
============================================================================
_______________________________________________
NetworkManager-list mailing list
[email protected]
http://mail.gnome.org/mailman/listinfo/networkmanager-list
