Netgate Discussion Forum
    • Categories
    • Recent
    • Tags
    • Popular
    • Users
    • Search
    • Register
    • Login

    OSPF Routing via OpenVPN

    Scheduled Pinned Locked Moved Routing and Multi WAN
    9 Posts 3 Posters 7.0k Views
    Loading More Posts
    • Oldest to Newest
    • Newest to Oldest
    • Most Votes
    Reply
    • Reply as topic
    Log in to reply
    This topic has been deleted. Only users with topic management privileges can see it.
    • M
      mrbnet
      last edited by

      Hello,

      I am working on a config which will use OSPF (quagga package) to dynamically distribute routes throughout a multi-site network. It seems with the default Quagga OSPF configuration and OpenVPN that OSPF is unable to communicate. If I push an IP of 172.20.0.2 to the secondary site will pickup the main sites routes. The default assigned address of 172.20.0.6 does not work.

      Here is the current setup

      Main Site
      WAN: Static InternetIP
      LAN: 192.168.30.0/24
      DMZ: 230.12.12.0/27
      SiteSiteVPN Tunnel Network: 172.20.0.0/20
      ovpnc1: 172.20.0.1

      Secondary Site
      WAN: Internet IP
      Lan1: 192.168.31.0/24
      Lan2: 192.168.40.0/24
      ovpnc1: 172.20.0.2

      Third Site
      WAN: Internet IP
      Lan1: 192.168.72.0/24
      Lan2: 192.168.73.0/24
      ovpnc1: 172.20.0.6

      The issues is the routes are not pushed if the VPN client has any other IP then 172.20.0.2. It may be a conflict with the way OpenVPN subnets the clients.

      ospfd.conf - main

      
      password xxxxx
      log syslog
      interface ovpns1
      
      router ospf
        ospf router-id 172.20.0.1
        redistribute connected
        network 172.20.0.0/30 area 0.0.0.1
      
      

      ospfd.conf - main

      
      password xxxxx
      log syslog
      interface ovpns1
      
      router ospf
        ospf router-id 172.20.0.1
        redistribute connected
        network 172.20..0/30 area 0.0.0.1
      
      

      ospfd.conf - secondary

      
      password xxxxx
      log syslog
      interface ovpns1
      
      router ospf
        ospf router-id 172.20.0.2
        redistribute connected
        network 172.20.0.0/30 area 0.0.0.1
      
      

      ospfd.conf - third

      
      password xxxxx
      log syslog
      interface ovpns1
      
      router ospf
        ospf router-id 172.20.0.6
        redistribute connected
        network 172.20.0.0/30 area 0.0.0.1
      
      

      All clients on the vpn can ping eachother. All traffic is currently allowed on openvpn and lan networks.

      Here are some tcpdumps from the ovpns1 interfaces:

      
      01:05:00.645706 IP 172.20.0.6 > ospf-all.mcast.net: OSPFv2, Hello, length 44
      01:05:02.345338 IP 172.20.0.1 > ospf-all.mcast.net: OSPFv2, Hello, length 44
      01:05:10.889100 IP 172.20.0.6 > ospf-all.mcast.net: OSPFv2, Hello, length 44
      01:05:11.461312 IP 172.20.0.6 > igmp.mcast.net: igmp v3 report, 1 group record(s)
      01:05:12.241513 IP 172.20.0.6 > igmp.mcast.net: igmp v3 report, 1 group record(s)
      01:05:12.364821 IP 172.20.0.1 > ospf-all.mcast.net: OSPFv2, Hello, length 44
      01:05:12.655843 IP 172.20.0.6 > ospf-all.mcast.net: OSPFv2, Hello, length 44
      01:05:12.850823 IP 172.20.0.6 > igmp.mcast.net: igmp v3 report, 1 group record(s)
      01:05:14.841257 IP 172.20.0.6 > igmp.mcast.net: igmp v3 report, 1 group record(s)
      01:05:22.384417 IP 172.20.0.1 > ospf-all.mcast.net: OSPFv2, Hello, length 44
      01:05:22.677488 IP 172.20.0.6 > ospf-all.mcast.net: OSPFv2, Hello, length 44
      01:05:27.647364 IP 172.20.0.6 > igmp.mcast.net: igmp v3 report, 1 group record(s)
      01:05:28.614764 IP 172.20.0.6 > ospf-all.mcast.net: OSPFv2, Hello, length 44
      01:05:28.660760 IP 172.20.0.6 > igmp.mcast.net: igmp v3 report, 1 group record(s)
      01:05:29.050521 IP 172.20.0.6 > igmp.mcast.net: igmp v3 report, 1 group record(s)
      01:05:32.403637 IP 172.20.0.1 > ospf-all.mcast.net: OSPFv2, Hello, length 44
      01:05:38.619558 IP 172.20.0.6 > ospf-all.mcast.net: OSPFv2, Hello, length 44
      01:05:42.423084 IP 172.20.0.1 > ospf-all.mcast.net: OSPFv2, Hello, length 44
      01:05:48.644756 IP 172.20.0.6 > ospf-all.mcast.net: OSPFv2, Hello, length 44
      01:24:24.457922 IP 172.20.0.1 > ospf-all.mcast.net: OSPFv2, Hello, length 48
      01:24:32.880434 IP 172.20.0.2 > ospf-all.mcast.net: OSPFv2, Hello, length 48
      01:24:34.469888 IP 172.20.0.1 > ospf-all.mcast.net: OSPFv2, Hello, length 48
      01:24:42.880652 IP 172.20.0.2 > ospf-all.mcast.net: OSPFv2, Hello, length 48
      01:24:44.488665 IP 172.20.0.1 > ospf-all.mcast.net: OSPFv2, Hello, length 48
      
      1 Reply Last reply Reply Quote 0
      • M
        mrbnet
        last edited by

        I haven't made any progress on this setup. It seems to me this might be more of a Quagga/OSPF issues since the VPN connection seems to be connecting properly and all routers can ping each other.

        Here is another tcpdump from ovpnc1 on the third site. It looks like the OSPF packets are getting there. The second site is currently offline which is why it doesn't show here.

        
        13:36:40.815262 IP 172.20.0.6 > ospf-all.mcast.net: OSPFv2, Hello, length 44
        13:36:48.491709 IP 172.20.0.1 > ospf-all.mcast.net: OSPFv2, Hello, length 44
        13:36:50.826149 IP 172.20.0.6 > ospf-all.mcast.net: OSPFv2, Hello, length 44
        13:36:58.515281 IP 172.20.0.1 > ospf-all.mcast.net: OSPFv2, Hello, length 44
        13:37:00.836968 IP 172.20.0.6 > ospf-all.mcast.net: OSPFv2, Hello, length 44
        13:37:08.533942 IP 172.20.0.1 > ospf-all.mcast.net: OSPFv2, Hello, length 44
        13:37:10.847816 IP 172.20.0.6 > ospf-all.mcast.net: OSPFv2, Hello, length 44
        13:37:18.550568 IP 172.20.0.1 > ospf-all.mcast.net: OSPFv2, Hello, length 44
        13:37:20.858672 IP 172.20.0.6 > ospf-all.mcast.net: OSPFv2, Hello, length 44
        13:37:28.577445 IP 172.20.0.1 > ospf-all.mcast.net: OSPFv2, Hello, length 44
        13:37:30.869515 IP 172.20.0.6 > ospf-all.mcast.net: OSPFv2, Hello, length 44
        13:37:38.588860 IP 172.20.0.1 > ospf-all.mcast.net: OSPFv2, Hello, length 44
        13:37:40.880365 IP 172.20.0.6 > ospf-all.mcast.net: OSPFv2, Hello, length 44
        
        
        1 Reply Last reply Reply Quote 0
        • jimpJ
          jimp Rebel Alliance Developer Netgate
          last edited by

          I haven't seen that sort of config work before with SSL/TLS and a dynamic client subnet.

          I've only seen it work with point-to-point type setups - Shared key or SSL/TLS with a /30 - only in that way can both ends latch onto the actual "real" interface and see the traffic they expect to see and handle multicast.

          It might work on 2.1 with a large tap setup or topology-subnet. I havne't tried those.

          Remember: Upvote with the 👍 button for any user/post you find to be helpful, informative, or deserving of recognition!

          Need help fast? Netgate Global Support!

          Do not Chat/PM for help!

          1 Reply Last reply Reply Quote 0
          • M
            mrbnet
            last edited by

            I am trying to avoid creating a separate OpenVPN instance for each tunnel due to scaleability reasons. We're pushing static addresses to the OpenVPN clients via Client Specific Overrides within the 172.20.0.0/20 subnet. EX: ifconfig-push 172.20.0.6 172.20.0.5.

            So the issues is that the quagga cannot latch onto 172.20.0.5 and hear the multicast traffic from 172.20.0.6 even though TCPdump receives it through the interface? Is that a limitation of the Quagga package?

            I will take 2.1 for a spin and see what happens. Any other scalable suggestions?

            1 Reply Last reply Reply Quote 0
            • jimpJ
              jimp Rebel Alliance Developer Netgate
              last edited by

              As I mentioned, using tap or maybe topology-subnet might work and scale.

              Remember: Upvote with the 👍 button for any user/post you find to be helpful, informative, or deserving of recognition!

              Need help fast? Netgate Global Support!

              Do not Chat/PM for help!

              1 Reply Last reply Reply Quote 0
              • R
                rubic
                last edited by

                I can confirm that Quagga works with OpenVPN in 'Peer to Peer ( SSL/TLS)' and 'Remote Access ( SSL/TLS + User Auth)' mode when OpenVPN network topology is 'subnet'. So put 'topology subnet' in OpenVPN server Advanced configuration and you are done.

                1 Reply Last reply Reply Quote 0
                • M
                  mrbnet
                  last edited by

                  Did you need to have any of the openvpn interface ports assigned as interfaces? I have enabled "toplogy subnet" in the openvpn server configuration. All 3 vpn clients can ping each other and are exchanging ospf broadcasts. Rules are setup on all of the openvpn tabs to allow everything. The routing tables are getting updated across clients as well however the networks behind the pfsense boxes cannot ping the other networks. Running tcpdump on the router of the network initiating the ping doesn't show anything except for ospf traffic.

                  Might the traffic not be getting routed to the correct interface?

                  1 Reply Last reply Reply Quote 0
                  • M
                    mrbnet
                    last edited by

                    So it appears that tcpdumps on the client ovpn interfaces do show echo requests originating from the client to subnets behind the server. This traffic still isn't seen on the ovpns interface. It seems like there is some sort of routing issue. None of the local IPs are showing in the filter logs and all openvpn interfaces have allow all rules.

                    1 Reply Last reply Reply Quote 0
                    • R
                      rubic
                      last edited by

                      Hi, mrbnet!
                      Sorry I was wrong. Despite the OSPF routes already there, you have to put 'iroute' statement with net behind client's gateway in 'Client specific overrides - Advanced' on the server side for each client. It seems to be double work, but this is how OpenVPN works in 'Peer to Peer ( SSL/TLS)' mode.
                      I myself use OSPF for failover only and do not need to expose my home net to main office, so I do SNAT at home and 'Remote Access ( SSL/TLS + User Auth)' . Somehow it works without 'iroute' at the server side/

                      1 Reply Last reply Reply Quote 0
                      • First post
                        Last post
                      Copyright 2025 Rubicon Communications LLC (Netgate). All rights reserved.