Created
October 3, 2011 23:42
-
-
Save jessereynolds/1260554 to your computer and use it in GitHub Desktop.
Problem with multiple default routes on mac os x 10.7.1 (Lion)
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
| Well this is annoying. | |
| Today I am using USB to my iPhone 3GS for internet access on Telstra next-g. Things work fine. Network System Preferences says "iPhone USB is currently active and has the IP address 172.20.10.2.". | |
| Here's the routing table: | |
| Destination Gateway Flags Refs Use Netif Expire | |
| default 172.20.10.1 UGSc 77 6 en3 | |
| 127 127.0.0.1 UCS 0 0 lo0 | |
| 127.0.0.1 127.0.0.1 UH 9 8776 lo0 | |
| 169.254 link#7 UCS 0 0 en3 | |
| 172.16.147/24 link#9 UC 2 0 vmnet8 | |
| 172.16.147.255 ff:ff:ff:ff:ff:ff UHLWbI 0 24 vmnet8 | |
| 172.16.253/24 link#8 UC 2 0 vmnet1 | |
| 172.16.253.255 ff:ff:ff:ff:ff:ff UHLWbI 0 24 vmnet1 | |
| 172.20.10/28 link#7 UCS 3 0 en3 | |
| 172.20.10.1 2a:e7:cf:a6:c4:da UHLWIi 78 43 en3 119 | |
| 172.20.10.2 127.0.0.1 UHS 0 0 lo0 | |
| 172.20.10.15 ff:ff:ff:ff:ff:ff UHLWbI 0 24 en3 | |
| DNS servers are as follows and are contactable: | |
| jesse@Ren ~ $ cat /etc/resolv.conf | |
| # | |
| # Mac OS X Notice | |
| # | |
| # This file is not used by the host name and address resolution | |
| # or the DNS query routing mechanisms used by most processes on | |
| # this Mac OS X system. | |
| # | |
| # This file is automatically generated. | |
| # | |
| nameserver 10.4.176.231 | |
| nameserver 10.4.85.135 | |
| jesse@Ren ~ $ ping 10.4.176.231 | |
| PING 10.4.176.231 (10.4.176.231): 56 data bytes | |
| 64 bytes from 10.4.176.231: icmp_seq=0 ttl=250 time=527.240 ms | |
| 64 bytes from 10.4.176.231: icmp_seq=1 ttl=250 time=117.395 ms | |
| 64 bytes from 10.4.176.231: icmp_seq=2 ttl=250 time=104.456 ms | |
| 64 bytes from 10.4.176.231: icmp_seq=3 ttl=250 time=103.833 ms | |
| 64 bytes from 10.4.176.231: icmp_seq=4 ttl=250 time=102.884 ms | |
| ^C | |
| --- 10.4.176.231 ping statistics --- | |
| 5 packets transmitted, 5 packets received, 0.0% packet loss | |
| round-trip min/avg/max/stddev = 102.884/191.162/527.240/168.123 ms | |
| jesse@Ren ~ $ ping 10.4.85.135 | |
| PING 10.4.85.135 (10.4.85.135): 56 data bytes | |
| 64 bytes from 10.4.85.135: icmp_seq=0 ttl=250 time=96.857 ms | |
| 64 bytes from 10.4.85.135: icmp_seq=1 ttl=250 time=134.565 ms | |
| 64 bytes from 10.4.85.135: icmp_seq=2 ttl=250 time=132.878 ms | |
| 64 bytes from 10.4.85.135: icmp_seq=3 ttl=250 time=212.464 ms | |
| 64 bytes from 10.4.85.135: icmp_seq=4 ttl=250 time=150.857 ms | |
| ^C | |
| --- 10.4.85.135 ping statistics --- | |
| 5 packets transmitted, 5 packets received, 0.0% packet loss | |
| round-trip min/avg/max/stddev = 96.857/145.524/212.464/37.836 ms | |
| When I enable the PPTP VPN to my company's VPN server, it adds a second default route. So the ipv4 routing table looks like this: | |
| Internet: | |
| Destination Gateway Flags Refs Use Netif Expire | |
| default 172.20.10.1 UGSc 61 0 en3 | |
| default 10.32.33.129 UGScI 1 0 ppp0 | |
| 10 ppp0 USc 3 0 ppp0 | |
| 10.32.33.129 10.32.33.228 UH 1 0 ppp0 | |
| 117.53.160.14 172.20.10.1 UGHS 0 0 en3 | |
| 127 127.0.0.1 UCS 0 0 lo0 | |
| 127.0.0.1 127.0.0.1 UH 9 1167 lo0 | |
| 169.254 link#7 UCS 0 0 en3 | |
| 172.16.147/24 link#9 UC 2 0 vmnet8 | |
| 172.16.147.255 ff:ff:ff:ff:ff:ff UHLWbI 0 59 vmnet8 | |
| 172.16.253/24 link#8 UC 2 0 vmnet1 | |
| 172.16.253.255 ff:ff:ff:ff:ff:ff UHLWbI 0 59 vmnet1 | |
| 172.20.10/28 link#7 UCS 3 0 en3 | |
| 172.20.10.1 2a:e7:cf:a6:c4:da UHLWIi 61 35 en3 769 | |
| 172.20.10.2 127.0.0.1 UHS 0 0 lo0 | |
| 172.20.10.15 ff:ff:ff:ff:ff:ff UHLWbI 0 59 en3 | |
| And now, I can't access Telstra's DNS servers anymore: | |
| jesse@Ren ~ $ host -v www.va.com.au | |
| Trying "www.va.com.au" | |
| ^Cjesse@Ren ~ $ ping 10.4.176.231 | |
| PING 10.4.176.231 (10.4.176.231): 56 data bytes | |
| Request timeout for icmp_seq 0 | |
| Request timeout for icmp_seq 1 | |
| ^C | |
| --- 10.4.176.231 ping statistics --- | |
| 3 packets transmitted, 0 packets received, 100.0% packet loss | |
| jesse@Ren ~ $ ping 10.4.85.135 | |
| PING 10.4.85.135 (10.4.85.135): 56 data bytes | |
| Request timeout for icmp_seq 0 | |
| Request timeout for icmp_seq 1 | |
| ^C | |
| --- 10.4.85.135 ping statistics --- | |
| 3 packets transmitted, 0 packets received, 100.0% packet loss | |
| Sniffing the ppp0 network interface of the VPN connection I can see that it's trying to contact the Telstra nameservers via the VPN tunnel: | |
| jesse@Ren ~ $ ifconfig ppp0 | |
| ppp0: flags=8051<UP,POINTOPOINT,RUNNING,MULTICAST> mtu 1444 | |
| inet 10.32.33.228 --> 10.32.33.129 netmask 0xff000000 | |
| jesse@Ren ~ $ sudo tcpdump -i ppp0 -n | |
| tcpdump: verbose output suppressed, use -v or -vv for full protocol decode | |
| listening on ppp0, link-type PPP (PPP), capture size 65535 bytes | |
| 09:53:59.095958 IP 10.32.33.228.54028 > 10.4.85.135.53: 21969+ A? talkgadget.google.com. (39) | |
| 09:53:59.261916 IP 59.167.233.94 > 10.32.33.228: ICMP host 10.4.85.135 unreachable, length 36 | |
| .... So how does it decide which 'default route' to use for traffic when there are two of them, and they are both to private IP address spaces (172.20.10.1 and 10.32.33.129). I would have thought it'd use the service ordering defined in the Mac's Network preferences, otherwise what is 'set service order' for? The VPN connection is below the iPhone USB connection. | |
| So is it just looking at the first octet, finding that it's "10", and deciding to send the traffic down a default route that matches the first octet? Surely that's braindead behaviour? | |
| Workaround: | |
| For now adding a more specific route to Telstra's nameservers fixes it: | |
| jesse@Ren ~ $ sudo route add -net 10.4.0.0/16 172.20.10.1 | |
| add net 10.4.0.0: gateway 172.20.10.1 | |
| jesse@Ren ~ $ host www.va.com.au | |
| www.va.com.au has address 203.15.106.23 |
@ixsndl I found out why. I could not have been less pleased, so I'll share.
What does not work is changing various metrics on the route or deleting re-adding routes:
sudo route change 0.0.0.0/0 172.17.2.1 -hopcount=4
Also it does not work to change metrics on the interface:
sudo ifconfig en4 metric 13
What does work is reordering your network services.
View current order:
networksetup -listnetworkserviceorder
Set a new order:
sudo networksetup -ordernetworkservices "Wi-Fi" "MiFi 7730L" "Bluetooth PAN"
Verify the interface being used for default routes has successfully changed!:
route get 8.8.8.8
$sudo reboot
Will solve ur issue quickly
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
This behaviour still seems to exist. Did you ever find out why OSX choses a seemingly "random" route?