0

On my home network (10.0.1.0/24) I have my Macs and iOS devices (the others don't matter). LAN clients gain IPv4 and IPv6 (native) access via an Airport Extreme (AEBS) connected to a cable modem on Comcast (I have no better choice). I require a VPN to access some $work resources and it'd be convenient if the VPN "just worked" on whichever screen I have at hand. To avoid managing a VPN client on each device, I run OpenVPN on my server (10.0.1.252).

Upon connection to the VPN, the server gets the typical static routes added and I've enabled forwarding and NAT so traffic from $private_lan -> <vpn_netblocks> is properly NAT routed down the VPN tunnel (tun0). My DNS recursor runs on that server and knows to forward certain DNS requests to the internal DNS servers. It all works.

The last bit is to make the LAN clients aware of the VPN. Their default route is the AEBS (10.0.1.1). This is ideal because the AEBS & cable modem have their own battery so the network stays up many hours after the power goes out. For LAN clients to gain VPN access, they need to learn of the more specific routes available on the server. On Mac OS, manually adding static routes like this works:

route add 10.7.0.0/16 10.0.1.252

The question is how to automatically inform the Mac and iOS devices those routes are available. I cannot add static routes to the AEBS (I'd be delighted to be proven wrong!). Changing the default IPv4 route to point at the server is my last resort.

I tried adding the routes to dhcpd.conf as static routes (dhcp option code 121), as documented in RFC 3442. Here are the relevant portions of my dhcpd.conf:

# options for static routes
option rfc3442-classless-static-routes code 121 = array of integer 8;
option ms-classless-static-routes code 249 = array of integer 8;

subnet 10.0.1.0 netmask 255.255.255.0 {
      option rfc3442-classless-static-routes 16, 10,7, 10,0,1,252;
      option ms-classless-static-routes      16, 10,7, 10,0,1,252;
      # needed b/c this overrides option routers
      option rfc3442-classless-static-routes  0, 10,0,1,1;
      option ms-classless-static-routes       0, 10,0,1,1;
}

The options are being served by dhcpd but they are ignored by Mac OS X. Is there:

  1. Some other DHCP option that does work?
  2. If I set up OSPF or RIP will it "just work" for both Mac and iOS devices?
  3. Something like Neighbor Discovery Protocol for IPv4?

Pointers to documentation that is known to work is greatly appreciated.

Update

  1. Added dhcpd.conf showing my config
  2. Added link to Apple Discussion citing no support for RFC 3442

migrated from serverfault.com Feb 6 '15 at 20:12

This question came from our site for system and network administrators.

  • Heck, I'm impressed you got that far! Nice solution and I'll follow this to see where it goes. – SaxDaddy Feb 6 '15 at 21:09
0

Can't you just set the default gateway of your LAN clients to point at the OpenVPN server? That is already a router, that should know all the correct routes.

I assume that is on your lan so the local clients can reach it. It will know to forward stuff to the OpenVPN network. It will either forward stuff to your border router, or send an ICMP redirect for system trying to communicate with Internet.

  • And I quote myself, "Changing the default IPv4 route to point at the server is my last resort." – Matt Simerson Feb 7 '15 at 3:34
0

Ad.1 I am not a OS X expert but you can try to setup DHCP option 249 (ms-classless-static-routes) like this:

option ms-classless-static-routes 24, 192, 168, 16, 192, 168, 6, 1; 
24 - mask (number of bits)
192, 168, 16 - network address
192, 168, 6, 1 - gateway

There's also DHCP option 33 (Single route): - https://ercpe.de/blog/advanced-dhcp-options-pushing-static-routes-to-clients

Single route

Pushing a single route is very easy. The configuration value consists of two ip address pairs in hex. The first address is the destination host, the second is the router.

Example:

Destination: 192.168.123.234 (Hex: C0:A8:7B:EA)
Router: 10.34.72.42 (Hex: 0A:22:48:2A)

The value is: C0:A8:7B:EA:0A:22:48:2A

Note: This is pfsense configuration, to use it in dhcpd you need to convert hex to decimal.

It's possible that you did some mistake, can you show us dhcpd configuration?

Very good description is here: https://ercpe.de/blog/pushing-static-routes-with-isc-dhcp-server

Pushing static routes to your dhcp clients with pfsense was tricky because you have to specify the network and router informations as the raw hex values. Accomplishing the same task with the ISC DHCP server is easier. First of all, we have to declare the dhcp option in the global scope to the server:

option rfc3442-classless-static-routes code 121 = array of integer 8;
option ms-classless-static-routes code 249 = array of integer 8;

The second line is for Windows clients, because MS decided to use the dhcp option 249 instead of the existing 121. The next step is to declare these options in our subnet definition:

 subnet 192.168.1.0 netmask 255.255.255.0 {
     ... other options ....
     option rfc3442-classless-static-routes 24, 192, 168, 123, 10, 10, 10, 1, 0, 192, 168, 1, 2;
     option ms-classless-static-routes 24, 192, 168, 123, 10, 10, 10, 1, 0, 192, 168, 1, ;
 }

The format of the options is:

<netmask>, <network-byte1>, <network-byte2>, <network-byte3>, <router-byte1>, <router-byte2>, <router-byte3>

where bytes with the value 0 are omitted. Again, you should include the default route in the options because dhcp clients are allowed to ignore the option routers x.x.x.x option. So, the line option rfc3442-classless- static-routes 24, 192, 168, 123, 10, 10, 10, 1, 0, 192, 168, 1, 2 specifies the following routing informations:

24, 192, 168, 123, 10, 10, 10, 1: 192.168.123.0/24 via 10.10.10.1 0,
192, 168, 1, 2: 0.0.0.0 via 192.168.1.2 (default route)

Make sure to read the comments as well.

There's also other thread @ serverfault which may be useful:

https://serverfault.com/questions/248821/does-the-os-x-dhcp-client-support-classless-static-routes-rfc3442

One other thing: are u aware of OpenVPN's push option? You can push routes directly via OpenVPN server by adding option like this:

push "route 192.168.16.0 255.255.255.0 192.168.6.1" 

Which means pass static route to client for network 192.168.16.0 and mask 255.255.255.0 via 192.168.6.1.

  • Thanks Michal. It doesn't really answer the question (I still don't have a way to push routes to my Mac and iOS devices), but it does include some helpful references. When I get enough reputation, I'll vote it up. FTR, I did also include and test DHCP option 249 but that didn't work either. I'll update the question to show my dhcpd.conf. – Matt Simerson Feb 9 '15 at 5:33
  • Have you tried DHCP option 33 as well? – Michal Sokolowski Feb 9 '15 at 8:13
  • DHCP option 33 adds a route for a single IP address. In a case like this, where I have a handful of /16 blocks (65,534 addrs each) to route, that really would not be helpful. It appears that quagga adds several routing daemons to Mac OS (available in MacPorts) so that could work for Mac OS X. – Matt Simerson Feb 9 '15 at 19:46
  • Yes, I aware of OpenVPN's push option. In this case my server is the OpenVPN client and it is the recipient of those pushed routes. That's how, "Upon connection to the VPN, the server gets the typical static routes added." – Matt Simerson Feb 9 '15 at 20:19
  • Okay, now I got it. :) Have you thought about adding static route(s) on your main router pointing to your VPN network via your server? – Michal Sokolowski Feb 10 '15 at 2:03
0

It appears the correct answer to the question is, "you can't."

Mac OS X (and iOS) do not support RFC 3442 and although Mac OS X 10.10 still includes the man page for routed, the binary is no longer present.

There are workarounds.

  1. To inform Mac OS X clients of the more specific routes, one can run a routing daemon on Mac OS X via a software package called quagga that includes ripd and ospfd, which can then learn of the OpenVPN routes from the equivalent daemons on the server (routed, quagga, zebra). This is a lot of bother to avoid #2.

  2. Point the default IPv4 route at the server (instead of the router) and use a short DHCP lease. When the server is unavailable, the DHCP lease expires quickly and the devices pick up a new lease from the AEBS with itself as the default gateway.

(Yes, I have two DHCP servers on my LAN, been doing it for over a decade, the dhcpd on the server wins except when it's down, which is to say, it works perfectly).

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.