Project

General

Profile

Actions
Copy link

Bug #3713

closed

Gateways missing for OpenVPN server (shared key or /30s)

Added by Dmitriy K over 10 years ago. Updated almost 10 years ago.

Status:
Resolved
Priority:
Normal
Assignee:
-
Category:
OpenVPN
Target version:
2.2
Start date:
06/15/2014
Due date:
% Done:

100%

Estimated time:
Plus Target Version:
Release Notes:
Affected Version:
2.2
Affected Architecture:
Actions
Copy link
 #1

Updated by Renato Botelho over 10 years ago

  • Target version changed from 2.2 to Future

Can you please add more information about what issue you are trying to get fixed here?

Actions
Copy link
 #2

Updated by Renato Botelho over 10 years ago

Maybe you were seeing issues like #3475?

Actions
Copy link
 #3

Updated by Chris Buechler over 10 years ago

  • Target version changed from Future to 2.2

This should be an easy fix. Where you have a tap OpenVPN server configured, a dynamic gateway is added that has no IP assigned for the gateway in rules.debug. It should just skip adding dynamic gateways for all OpenVPN servers, right now it only skips that for those with tun interfaces. For instance, this (after filling in a shared key) will show the issue:

        <openvpn-server>
            <vpnid>3</vpnid>
            <mode>p2p_shared_key</mode>
            <protocol>UDP</protocol>
            <dev_mode>tap</dev_mode>
            <ipaddr/>
            <interface>wan</interface>
            <local_port>1201</local_port>
            <description><![CDATA[UDP shared key tap test]]></description>
            <custom_options/>
            <shared_key></shared_key>
            <crypto>AES-256-CBC</crypto>
            <digest>SHA1</digest>
            <engine>none</engine>
            <tunnel_network/>
            <tunnel_networkv6/>
            <remote_network/>
            <remote_networkv6/>
            <gwredir/>
            <local_network/>
            <local_networkv6/>
            <maxclients/>
            <compression/>
            <passtos/>
            <client2client/>
            <dynamic_ip/>
            <pool_enable>yes</pool_enable>
            <topology_subnet/>
            <serverbridge_dhcp/>
            <serverbridge_interface/>
            <serverbridge_dhcp_start/>
            <serverbridge_dhcp_end/>
            <netbios_enable/>
            <netbios_ntype>0</netbios_ntype>
            <netbios_scope/>
        </openvpn-server>
Actions
Copy link
 #4

Updated by Renato Botelho over 10 years ago

  • Status changed from New to Feedback
  • % Done changed from 0 to 100

Pull request has been merged

Actions
Copy link
 #5

Updated by Anonymous over 10 years ago

Actions
Copy link
 #6

Updated by Chris Buechler about 10 years ago

  • Status changed from Feedback to Resolved
Actions
Copy link
 #7

Updated by Jim Pingle almost 10 years ago

  • Status changed from Resolved to Confirmed
  • % Done changed from 100 to 0

The fix for this is incorrect. It also excludes tun servers, not only tap servers as the ticket title stated was a problem.

Gateways are valid and required for tun-based OpenVPN servers. At least for those using Shared Key, or SSL/TLS with a /30 tunnel network.

Actions
Copy link
 #8

Updated by Chris Buechler almost 10 years ago

  • Subject changed from Do not generate gateways for OpenVPN server TAP endpoints to Gateways missing for OpenVPN server (shared key or /30s)
  • Affected Version changed from All to 2.2
Actions
Copy link
 #9

Updated by Chris Buechler almost 10 years ago

  • Status changed from Confirmed to Feedback
  • % Done changed from 0 to 100
Actions
Copy link
 #10

Updated by Chris Buechler almost 10 years ago

Pretty sure this should be fine now. Leaving for sanity check from JimP.

Actions
Copy link
 #11

Updated by Jim Pingle almost 10 years ago

I created and assigned a tun and a tap static key and the tun received a gateway, the tap did not.

There are cases where tap might use a gateway but the old behavior wouldn't have worked properly for that anyhow as far as I can see, since it was putting in a bogus/incorrect auto entry. Looks good for now, can probably close it out.

Actions
Copy link
 #12

Updated by Chris Buechler almost 10 years ago

  • Status changed from Feedback to Resolved

yeah the tap scenario before would result in an invalid ruleset previously. This brings back the same behavior as prior releases in every circumstance I can think of.

Actions
Copy link

Also available in: Atom PDF