Multiple ethernet controlers...

I am working with a Dell Poweredge 2590. It has 2 ethernet ports. They work nicely, except… One or the other MUST be the default route?


Default route:

This are static IP’s.

If I configure a VPN using openpn over IP ranges 10.0.0.x , and put it on Eth1 I get all sorts of routing issues. The first is that if I specify that Eth0 is the primary ethernet connection in yast, then the VPM fails to load/bind to the eth1 port. If I specify Eth1 as the default port, then web/ssh/ftp cannot access thee server on eth0.

I’ve tried even setting the ‘defalt’ to “-” but that doesn’t help either.

2950 you mean I think.

There’s very little gain in putting both eth interfaces on the same subnet, unless you have a switch that supports bonding. So don’t do it.

OpenVPN’s interfaces should be bound to tun or tap devices, not to eth devices so there’s no problem with giving them a different subnet.

Additional info…
I have a test machine (generic machine) with 3 3com ethernet cards in it. The same thing happens on that machine without the VPN.

Eth1: Public IP
Eth0: 192.168.1.x (dhcp)
Eth2: 10.0.0.x (dhcp)

I set Eth1 as the ‘default’ in yast. If for some reason it goes down (such as disconnecting the ethernet cable) all 3 ports won’t route.

If I set Eth0 as the ‘default’ the eth1 IP is not acessable. If for some reason the Eth0 port is disconnected, the other 2 fair to work as well.

Similar happsn if the eth2 is specified.

If I don’t specify a default hardware port, none of them work.

If I specify a “-” as teh default port, it again fails. It did not do this in Opensuse 10.1 which is what the boxes were upgraded from. The test machine is easily configurable so I can test things as needed.

There can only be one default route and this is normally put in the interface with the most destinations, i.e. the one to the Internet. However if the public interface goes down you should still be able to route from 192.168.1.x to 10.0.0.x, provided you have IP forwarding enabled and your firewall rules allow it.

You sound like another poster who had traffic cameras on a third interface. Are you related?

Not related to the other poster.

The problem is that in the first example, the 2 ethernet cards are going to be 2 seperate public addresses on the same subnet. The eth0 ip will be for webhosting, etc the second IP address, which will be on Eth1 will be for the VPN so as not to mix the traffic. (it caused a lot of issues in OpenSuSE 10.1, which is why we set up the original box this way)

The text box is configured not as a bridge between the different subnet, just as a client on all 3 of them. If any of the cables/conections go down, I should still be able to access the still working subnets, at least. This does not work, when it goes through the NAT router from either the 10.0.0.x or 192.168.1.x subnets if the main Public link is down at this machine (still working for everyone else). 3 seperate networks. 1 public, 2 private each with a NAT’d router with an external public IP. This setup is used for testing different configureations and servers.

VPN interfaces use a tun or a tap device and don’t require a physical eth device. So you can take that out of the equation.

If you are not routing, then yes, you should be able to reach the various subnets from the server. Check that you are not relying on a DNS service to resolve domain names which also become unavailable when the public interface goes down. And check that when the public interface goes down it doesn’t deconfigure any routing on the other interfaces.

Already checked. Using ping tests by IP when testing.

THe VPM binds to the IP, then creates a virutal interface. The problem is that we don’t want it to bind to the publicly acessable IP address on eth0. We want it bound to the secondary IP on eth1.

You keep telling me not to worry about the VPN. You are missing the point. We WANT it on the second card/IP so as not to interfear like it did with OpenSuSE 10.1 with the traffic on the first IP. Problem is that it still tries routing it through the first device, and/or won’t properly bind to the second device.

The entire reason for having 2 devices is redundancy. The VPN is secondary, and can be ignored, if you must. If the first one fails, the second one can take over, but it won’t take over because if the first one fails, it still tries to route everything though it. This doesn’t work on OpenSuSe 11.2.

I’ve never had to bind OpenVPN to a real interface. It routes using a real interface of course, but you don’t have to bind it to a real interface. You may be confusing it with the interface it’s routing through. In which case that interface should be configured as appropriate for the link. Again, in this case the fact that you are using VPN is irrelevant, you just configure that interface as the link requires.

Redundancy is a different issue. I confess to having no experience with redundant interfaces, but I suspect you are better off with one active interface (with multiple IP addresses bound to it) and failover to the second interface. You might want to see how it’s done in high availability setups where redundant servers share an IP address and a secondary server takes over at the same address when the first one drops out. There are probably some tools there you can use.