Bug 490437 - No way to create a default route in nm-applet
No way to create a default route in nm-applet
Status: CLOSED DUPLICATE of bug 528281
Product: Fedora
Classification: Fedora
Component: NetworkManager (Show other bugs)
11
All Linux
low Severity medium
: ---
: ---
Assigned To: Dan Williams
Fedora Extras Quality Assurance
: Reopened
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2009-03-16 09:03 EDT by gene c
Modified: 2009-11-11 11:36 EST (History)
2 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2009-11-11 11:36:09 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description gene c 2009-03-16 09:03:46 EDT
Description of problem: nm-applet does not allow the creation of a default route. I was in vpn - but the gui looks the same. The gui only allows numbers and hence the word 'default' is disallowed. However, it wont let 0.0.0.0 with a mask of 0.0.0.0 either.

So there is no way to enter the equivalent (in my vpn case) of

ip route add default dev tun0


Version-Release number of selected component (if applicable):
NetworkManager-0.7.0.99-3.fc10.i386


How reproducible:
always

Steps to Reproduce:
1. Click on nm applet to 'edit' connection
2. Click through to Routes
3. In address column attempt default (dissallowed) or 0.0.0.0 with mask of 0.0.0.0

It can be typed in but OK button is grayed out and not clickable
  
Actual results:
Cannot enter default and with 0.0.0.0 + 0.0.0.0 the OK button cannot be pressed to enter the route

Expected results:
Expect to be able to enter a default route

Additional info:
Comment 1 Dan Williams 2009-03-16 13:24:41 EDT
Is your intention to have your VPN *always* be the default route when it's active?  If so, your VPN server is probably sending static routes back to NM on connect, and NM assumes that means that the VPN should only be active for those routes (otherwise, why would the server send the routes, which are redundant if the VPN was the default route?).

To make the VPN always be the default route, check the "Ignore automatically obtained routes" box in the Routes dialog.  To get there, open up the connection editor by right-clicking on the applet's icon and selecting "Edit connections...", click the VPN tab, edit your connection, click the IPv4 tab in the connection's window, and then the "Routes..." button in that tab.

Let me know (by reopening the bug) if that doesn't do what you want, or if I've mis-understood what you're trying to do here.
Comment 2 gene c 2009-03-16 17:01:22 EDT
I did clicked 'Ignore automatically
obtained routes' - 

I do not get a default route -  With or without clicking that option.

This would be solved if the gui applet did not filter out 0.0.0.0 mask 0.0.0.0.

Thanks

gene
Comment 3 Dan Williams 2009-03-16 17:47:13 EDT
Ok, re-opening.  Which VPN service is this with, PPTP, vpnc, or openvpn?  Can you paste in the output of '/sbin/route -n' after making the connection, when the problem occurs?
Comment 4 gene c 2009-03-16 19:44:08 EDT
This is with vpnc.

 I am not on premises at the moment which is where this occurs. 

 I connect a wifi connection first - and then use vpnc (to cisco backend).

 I had put in by hand (in nm-applet) 3 routes which I had left in. The routes I got in the end included a host route (from the wireless connection) along with the 3 routes I added - i put in address and netmask - the routes created from those I put in were simply to dev tun0.

 The 3 routes I put in cover a good chunk of my needs, but not all - hence the need for a default route.

  Is this sufficient or do you need more ?
Comment 5 gene c 2009-03-17 10:12:37 EDT
 Mild obfuscation of IP addresses - here's the routes I get.

wifi connected (wlan0 ip aaa.27.146.24)
Destination     Gateway         Genmask         Flags   MSS Window  irtt Iface
aaa.27.144.0    0.0.0.0         255.255.252.0   U         0 0          0 wlan0

Vpn connected (tun0 ip bbb.168.93.2 )
bbb.168.93.0    0.0.0.0         255.255.255.0   U         0 0          0 tun0
aaa.27.144.0    0.0.0.0         255.255.252.0   U         0 0          0 wlan0
ccc.168.128.0   0.0.0.0         255.255.128.0   U         0 0          0 tun0
ddd.107.0.0     0.0.0.0         255.255.0.0     U         0 0          0 tun0
bbb.168.0.0     0.0.0.0         255.255.0.0     U         0 0          0 tun0


The 3 routes I added in nm-applet re the last 3 rows

By hand I do this to make things work after the vpn is connected.

ip ro add default dev tun0
Comment 6 Dan Williams 2009-03-23 17:48:33 EDT
To get the VPN being the default, you *do not* want to enter static routes in nm-connection-editor.  You want "Use this connection only for resources on its network" *unchecked*, and "Ignore automatically provided routes" *checked*.  Using this configuration, I get:

Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
aa.bb.cc.dd     10.16.15.254    255.255.255.255 UGH   0      0        0 eth2
10.16.10.0      0.0.0.0         255.255.254.0   U     0      0        0 tun0
10.16.12.0      0.0.0.0         255.255.252.0   U     2      0        0 eth2
0.0.0.0         0.0.0.0         0.0.0.0         U     0      0        0 tun0


and as expected, the default route is through the VPN.  By unchecking "Ignore automatically provided routes" in nm-connection-editor, the VPN is no longer the default route (as expected), and only the server-provided routes are VPN-enabled.

Please confirm that removing any manually specified routes, checking "Ignore..." and unchecking "Use this connection..." makes the VPN the default route for you.
Comment 7 gene c 2009-03-25 09:24:52 EDT
Thanks for thought - sorry to be slow in respondning have been unable to do this till now.

Doing what you said

  o Deleted all static routes
  o uncheck 'Use only for ...
  o check 'ignore automatically provided ..'

I do NOT get a default route i get this:

# netstat -rn
Kernel IP routing table
Destination     Gateway         Genmask         Flags   MSS Window  irtt Iface
bbb.168.93.0    0.0.0.0         255.255.255.0   U         0 0          0 tun0
aaa.27.144.0    0.0.0.0         255.255.252.0   U         0 0          0 wlan0


As an aside - is there any reason to disallow entering a default route in the applet - since you can add routes anyway ?

If it matters - the wifi connection is a hidden one (not my choice).

thanks for help ... may I please again to allow adding a default route anyway, regardless of buttons to click ?

thanks again.
Comment 8 gene c 2009-03-25 12:56:50 EDT
to be clear - above route info is in the vpn part of applet - the wireless part has nothing set for routes - no static routes and neither button is clicked.
Comment 9 gene c 2009-07-13 09:30:10 EDT
Update - problem persists :

 NetworkManager-0.7.1-4.git20090414.fc11.x86_64
 NetworkManager-vpnc.x86_64         1:0.7.0.99-1.fc11             installed      
 vpnc.x86_64                        0.5.3-3.fc11                  installed
Comment 10 Gene Czarcinski 2009-08-23 12:13:10 EDT
The problem persists on F11 and it is not just VPN stuff.

If you have only a single NIC, then there is only one possible default route and everything works.

If you have a system (such as a laptop) with both a wired and a wireless NIC, then everything works because only on will be active and any point in time (as controlled by NetworkManager).

However, if you have two or more NICs (real or pseudo), then things get screwed up and the last interface enabled will set the default route.

In my case, I have a qemu-kvm guest with two NICs.  The first NIC (eth0) can either be a bridged connection (on br0) or a NATed connection (on virbr0) the default route needs to point to this interface.  The second NIC (eth1) is connected to a private ("host-only") network on virbr2..

I have tried setting both GATEWAY=<ip_addr> and GATEWAYDEV=<device> and neither has any effect.
Comment 11 Dan Williams 2009-10-15 01:08:49 EDT
In the QEMU case, or in any case where you have multiple devices, there solution is slightly different for system and user connections.  First a short explanation of system and user connections...

system connections are stored in ifcfg files and are the normal ifcfg network files you've probably used before.  They are available to be used by NM before login and at system boot time, and by an user on the machine.

User connections are private to each user and are not available to other users, and their configuration is stored in GConf in the user's session.  They are only available when that user is logged in.

So it depends right now on what type of connection it is.  If the connection is stored in an ifcfg file, then GATEWAYDEV is the method you should use to ensure that the default route is via the device of your choice.  If it's a user connection, then you want to check the "Use this connection only for resources on its network" for the connections you do *not* want to ever have the default route.

So if you have 2 NICs and a VPN connection, and you want only eth0 and the VPN to get the default route, you would set GATEWAYDEV=eth0 and ensure the "Only use this connection for resources on its network" box is *un*checked.  Thus eth1 would never receive the default route, but eth0 would, and when the VPN was active, tun0 would have the default route.

Does that clear things up at all?  If not, can you tell me what connections you see in the 'wired' page of nm-connection-editor (right-click on the applet, choose Edit connections...) so that we can track down how you need to configure the default route?  What files do you have in /etc/sysconfig/network-scripts/ifcfg-* ?

Thanks!
Comment 12 Dan Williams 2009-11-10 20:05:26 EST
Should we dupe this bug to bug #528281 ?
Comment 13 Gene Czarcinski 2009-11-11 05:57:21 EST
Yes, I believe that this is a dup ... the patch to add DEFROUTE= should solve this user's problem.
Comment 14 Dan Williams 2009-11-11 11:36:09 EST

*** This bug has been marked as a duplicate of bug 528281 ***

Note You need to log in before you can comment on or make changes to this bug.