Thread Info
  • State Not Answered
  • Replies 15 replies
  • Subscribers 0 subscribers
  • Views 1595 views
  • Users 0 members are here
Options
Suggested

[7.910][BUG][CLOSED] SSL Site to Site Problem

Robert Tausend
I get a strange error message after i added a new interface to a tunnel ... and i can't connect to my main network anymore ...

Main Network 192.168.110.0/23 
Remte Network 192.168.0.0/24 and 192.168.1.0/24

Here is the Logentry:


2010:05:07-10:10:22 firewall openvpn[10997]: SIGTERM[soft,exit-with-notification] received, process exiting
2010:05:07-10:10:37 firewall openvpn[15516]: OpenVPN 2.1_rc13 i686-pc-linux-gnu [SSL] [LZO2] [EPOLL] built on Aug 24 2009
2010:05:07-10:10:37 firewall openvpn[15516]: WARNING: Make sure you understand the semantics of --tls-remote before using it (see the man page).
2010:05:07-10:10:37 firewall openvpn[15516]: NOTE: the current --script-security setting may allow this configuration to call user-defined scripts
2010:05:07-10:10:37 firewall openvpn[15516]: LZO compression initialized
2010:05:07-10:10:37 firewall openvpn[15516]: Control Channel MTU parms [ L:1554 D:138 EF:38 EB:0 ET:0 EL:0 ]
2010:05:07-10:10:37 firewall openvpn[15516]: Data Channel MTU parms [ L:1554 D:1200 EF:54 EB:135 ET:0 EL:0 AF:3/1 ]
2010:05:07-10:10:37 firewall openvpn[15516]: Local Options hash (VER=V4): 'a75583f2'
2010:05:07-10:10:37 firewall openvpn[15516]: Expected Remote Options hash (VER=V4): 'df0e0494'
2010:05:07-10:10:37 firewall openvpn[15517]: UDPv4 link local: [undef]
2010:05:07-10:10:37 firewall openvpn[15517]: UDPv4 link remote: X.X.X.X:1194
2010:05:07-10:10:37 firewall openvpn[15517]: WARNING: this configuration may cache passwords in memory -- use the auth-nocache option to prevent this
2010:05:07-10:10:38 firewall openvpn[15517]: VERIFY OK: depth=1, /C=de/L=Gilching/O=Ducktales/CN=Ducktales_VPN_CA/emailAddress=robert@rtausend.de
2010:05:07-10:10:38 firewall openvpn[15517]: VERIFY X509NAME OK: /C=de/L=Gilching/O=Ducktales/CN=firewall.ducktales.net/emailAddress=robert@rtausend.de
2010:05:07-10:10:38 firewall openvpn[15517]: VERIFY OK: depth=0, /C=de/L=Gilching/O=Ducktales/CN=firewall.ducktales.net/emailAddress=robert@rtausend.de
2010:05:07-10:10:39 firewall openvpn[15517]: Data Channel Encrypt: Cipher 'AES-128-CBC' initialized with 128 bit key
2010:05:07-10:10:39 firewall openvpn[15517]: Data Channel Encrypt: Using 128 bit message hash 'MD5' for HMAC authentication
2010:05:07-10:10:39 firewall openvpn[15517]: Data Channel Decrypt: Cipher 'AES-128-CBC' initialized with 128 bit key
2010:05:07-10:10:39 firewall openvpn[15517]: Data Channel Decrypt: Using 128 bit message hash 'MD5' for HMAC authentication
2010:05:07-10:10:39 firewall openvpn[15517]: Control Channel: TLSv1, cipher TLSv1/SSLv3 DHE-RSA-AES256-SHA, 1024 bit RSA
2010:05:07-10:10:39 firewall openvpn[15517]: [firewall.ducktales.net] Peer Connection Initiated with X.X.X.X:1194 (via 195.71.14.148)
2010:05:07-10:10:41 firewall openvpn[15517]: Options error: route parameter network/IP '192.16' must be a valid address
2010:05:07-10:10:41 firewall openvpn[15517]: TUN/TAP device tun1 opened
2010:05:07-10:10:41 firewall openvpn[15517]: /bin/ip link set dev tun1 up mtu 1500
2010:05:07-10:10:41 firewall openvpn[15517]: /bin/ip addr add dev tun1 local 10.242.111.18 peer 10.242.111.17
2010:05:07-10:10:41 firewall openvpn[15517]: Initialization Sequence Completed
2010:05:07-10:10:41 firewall openvpn[15517]: WARNING: Received unknown control message: .115.0 255.255.255.0,route 192.168.110.0 255.255.254.0 
Parents
  • 0
    Does it work when you make the V7 server and define these twelve networks as remote nets?

    Background: we added patches in V7 the worked around the conceptual problem in openvpn that the push buffer has a limited size. When pushing many routes to the client only some of those would have arrived at the client. Two things were made. First we aggregate networks. In your setup

        192.168.2.0/24 and
        192.168.3.0/24

    would be pushed as 

        192.168.2.0/23

    Second, if the length of pushed options would exceed the maximum length of the push buffer, chunked push buffers would be sent until the rest of the option will fit into the final regular push buffer. The client would then reassemble the chunked and the regular push buffers and apply the options. Here's where your problem is. It seems the V8 is not sending the chunks correctly. However, I'm currently in the process of removing most of the above functionality (besides a small V7 compat layer) in V8 as openvpn now comes with something similar than chunked push buffers. So, if V7 pushes the chunks correctly everything will be OK as V8 won't be the same pretty soon anyways.
Reply
  • 0
    Does it work when you make the V7 server and define these twelve networks as remote nets?

    Background: we added patches in V7 the worked around the conceptual problem in openvpn that the push buffer has a limited size. When pushing many routes to the client only some of those would have arrived at the client. Two things were made. First we aggregate networks. In your setup

        192.168.2.0/24 and
        192.168.3.0/24

    would be pushed as 

        192.168.2.0/23

    Second, if the length of pushed options would exceed the maximum length of the push buffer, chunked push buffers would be sent until the rest of the option will fit into the final regular push buffer. The client would then reassemble the chunked and the regular push buffers and apply the options. Here's where your problem is. It seems the V8 is not sending the chunks correctly. However, I'm currently in the process of removing most of the above functionality (besides a small V7 compat layer) in V8 as openvpn now comes with something similar than chunked push buffers. So, if V7 pushes the chunks correctly everything will be OK as V8 won't be the same pretty soon anyways.
Children
No Data
Cookie Information Banner