4. OSPF Routing via OpenVPN

OSPF Routing via OpenVPN

  • M

    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
    0
  • M

    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
    0
  • Rebel Alliance Developer Netgate

    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.

    0
  • M

    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?

    0
  • Rebel Alliance Developer Netgate

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

    0
  • R

    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.

    0
  • M

    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?

    0
  • M

    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.

    0
  • R

    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/

    0
Log in to reply
 

Products

Services

Support

News

Resources

Company

Our Mission

We provide leading-edge network security at a fair price - regardless of organizational size or network sophistication. We believe that an open-source security model offers disruptive pricing along with the agility required to quickly address emerging threats.

Subscribe to our Newsletter

Product information, software announcements, and special offers. See our newsletter archive for past announcements.

© Copyright 2019 Rubicon Communications, LLC | Privacy Policy