I have both cable and dsl service. The router attached to the cable service is 192.168.0.1 and the router attached to the dsl service is 192.168.0.254. I determine which service my computers communicate through by setting the gateway assignment to either of those addresses and it just works.
I can connect to my computers from the outside by port forwarding from my routers to the computer that I want to connect to.
However, the outside ssh connection works only if the computer's gateway assignment matches the router that I'm connecting to. I suspect that I have to set up some sort of routing assignment to tell the computer to reply to the gateway that the ssh connection request came in on if it doesn't match the current gateway assignment, but I have no idea how to do that.
On 11/10/2014 02:11 PM, Frank Cox wrote:
However, the outside ssh connection works only if the computer's gateway assignment matches the router that I'm connecting to. I suspect that I have to set up some sort of routing assignment to tell the computer to reply to the gateway that the ssh connection request came in on if it doesn't match the current gateway assignment, but I have no idea how to do that.
What you're describing is multi-homing, and it's fairly complex. You'll need to 1) create routing tables for each ISP, 2) mark incoming NEW connections based on the MAC of the router that forwarded the new connection, and 3) create ip rules to associate a connection with the correct routing table.
This article partially covers what you need to do, and might get you started: https://blogs.oracle.com/networking/entry/advance_routing_for_multi_homed
You might also consider using Shorewall to manage the tables and rules rather than handling that yourself: http://shorewall.net/MultiISP.html
On 11/10/2014 2:11 PM, Frank Cox wrote:
I have both cable and dsl service. The router attached to the cable service is 192.168.0.1 and the router attached to the dsl service is 192.168.0.254. I determine which service my computers communicate through by setting the gateway assignment to either of those addresses and it just works.
I can connect to my computers from the outside by port forwarding from my routers to the computer that I want to connect to.
However, the outside ssh connection works only if the computer's gateway assignment matches the router that I'm connecting to. I suspect that I have to set up some sort of routing assignment to tell the computer to reply to the gateway that the ssh connection request came in on if it doesn't match the current gateway assignment, but I have no idea how to do that.
I also have two ISPs at home. I have a Peplink to manage this now, but before that I some commands in rc.local. I had two networks and two NICs on my workstation. This used to work on CentOS 6.
############################## # symetric routing # ##############################
NIC1=eth0 IP1=192.168.1.6 GW1=192.168.1.1 NET1=192.168.1.0/24
NIC2=eth1 IP2=192.168.2.6 GW2=192.168.2.1 NET2=192.168.2.0/24
DEFGW=$GW2
cat << EOF > /etc/iproute2/rt_tables # # reserved values # 255 local 254 main 253 default 0 unspec # # local # #1 inr.ruhep
# symetric routing 101 T1 102 T2 EOF
# routing and default gateway for each interface ip route add $NET1 dev $NIC1 src $IP1 table T1 ip route add default via $GW1 table T1 ip route add $NET2 dev $NIC2 src $IP2 table T2 ip route add default via $GW2 table T2
# regular routes ip route add $NET1 dev $NIC1 src $IP1 ip route add $NET2 dev $NIC2 src $IP2
# preference for default route route delete default ip route add default via $DEFGW
# rules ip rule add from $IP1 table T1 ip rule add from $IP2 table T2
# enable routing echo 1 > /proc/sys/net/ipv4/ip_forward
Good luck, Jack
On 11/10/2014 05:38 PM, Jack Bailey wrote:
On 11/10/2014 2:11 PM, Frank Cox wrote:
I have both cable and dsl service. The router attached to the cable service is 192.168.0.1 and the router attached to the dsl service is 192.168.0.254. I determine which service my computers communicate through by setting the gateway assignment to either of those addresses and it just works.
I can connect to my computers from the outside by port forwarding from my routers to the computer that I want to connect to.
However, the outside ssh connection works only if the computer's gateway assignment matches the router that I'm connecting to. I suspect that I have to set up some sort of routing assignment to tell the computer to reply to the gateway that the ssh connection request came in on if it doesn't match the current gateway assignment, but I have no idea how to do that.
I also have two ISPs at home. I have a Peplink to manage this now, but before that I some commands in rc.local. I had two networks and two NICs on my workstation. This used to work on CentOS 6.
############################## # symetric routing # ##############################
NIC1=eth0 IP1=192.168.1.6 GW1=192.168.1.1 NET1=192.168.1.0/24
NIC2=eth1 IP2=192.168.2.6 GW2=192.168.2.1 NET2=192.168.2.0/24
DEFGW=$GW2
cat << EOF > /etc/iproute2/rt_tables # # reserved values # 255 local 254 main 253 default 0 unspec # # local # #1 inr.ruhep
# symetric routing 101 T1 102 T2 EOF
# routing and default gateway for each interface ip route add $NET1 dev $NIC1 src $IP1 table T1 ip route add default via $GW1 table T1 ip route add $NET2 dev $NIC2 src $IP2 table T2 ip route add default via $GW2 table T2
# regular routes ip route add $NET1 dev $NIC1 src $IP1 ip route add $NET2 dev $NIC2 src $IP2
# preference for default route route delete default ip route add default via $DEFGW
# rules ip rule add from $IP1 table T1 ip rule add from $IP2 table T2
# enable routing echo 1 > /proc/sys/net/ipv4/ip_forward
Good luck, Jack
I can verify the above works just fine if all you want to be able to do is reach your system from outside over either isp..
On Tue, Nov 11, 2014 at 5:53 AM, Steve Clark sclark@netwolves.com wrote:
On 11/10/2014 05:38 PM, Jack Bailey wrote:
On 11/10/2014 2:11 PM, Frank Cox wrote:
I have both cable and dsl service. The router attached to the cable service is 192.168.0.1 and the router attached to the dsl service is 192.168.0.254. I determine which service my computers communicate through by setting the gateway assignment to either of those addresses and it just works.
I can connect to my computers from the outside by port forwarding from my routers to the computer that I want to connect to.
However, the outside ssh connection works only if the computer's gateway assignment matches the router that I'm connecting to. I suspect that I have to set up some sort of routing assignment to tell the computer to reply to the gateway that the ssh connection request came in on if it doesn't match the current gateway assignment, but I have no idea how to do that.
I also have two ISPs at home. I have a Peplink to manage this now, but before that I some commands in rc.local. I had two networks and two NICs on my workstation. This used to work on CentOS 6.
############################## # symetric routing # ##############################
NIC1=eth0 IP1=192.168.1.6 GW1=192.168.1.1 NET1=192.168.1.0/24
NIC2=eth1 IP2=192.168.2.6 GW2=192.168.2.1 NET2=192.168.2.0/24
DEFGW=$GW2
cat << EOF > /etc/iproute2/rt_tables # # reserved values # 255 local 254 main 253 default 0 unspec # # local # #1 inr.ruhep
# symetric routing 101 T1 102 T2 EOF
# routing and default gateway for each interface ip route add $NET1 dev $NIC1 src $IP1 table T1 ip route add default via $GW1 table T1 ip route add $NET2 dev $NIC2 src $IP2 table T2 ip route add default via $GW2 table T2
# regular routes ip route add $NET1 dev $NIC1 src $IP1 ip route add $NET2 dev $NIC2 src $IP2
# preference for default route route delete default ip route add default via $DEFGW
# rules ip rule add from $IP1 table T1 ip rule add from $IP2 table T2
# enable routing echo 1 > /proc/sys/net/ipv4/ip_forward
Good luck, Jack
I can verify the above works just fine if all you want to be able to do is reach your system from outside over either isp..
I think that is a different scenario, though. Since the subnet addresses are the same for both routers, the OP must only have one NIC.
On Tue, Nov 11, 2014 at 11:32 AM, Frank Cox theatre@melvilletheatre.com wrote:
On Tue, 11 Nov 2014 10:12:58 -0600 Les Mikesell wrote:
I think that is a different scenario, though. Since the subnet addresses are the same for both routers, the OP must only have one NIC
Yes.
Can you tell where the packets are getting lost? Asymmetric routing is supposed to work per the IP design, but Red Hat thinks they know better and breaks it with their default settings: https://access.redhat.com/solutions/53031
However, I thought that only applied to multiple NICs. Can you tell if packets are coming in from the non-default router and the response sent to the default one? And if so, can you traceroute to the address where the connection attempt is originating?
On 11/11/2014 12:44 PM, Les Mikesell wrote:
On Tue, Nov 11, 2014 at 11:32 AM, Frank Cox theatre@melvilletheatre.com wrote:
On Tue, 11 Nov 2014 10:12:58 -0600 Les Mikesell wrote:
I think that is a different scenario, though. Since the subnet addresses are the same for both routers, the OP must only have one NIC
Yes.
Can you tell where the packets are getting lost? Asymmetric routing is supposed to work per the IP design, but Red Hat thinks they know better and breaks it with their default settings: https://access.redhat.com/solutions/53031
However, I thought that only applied to multiple NICs. Can you tell if packets are coming in from the non-default router and the response sent to the default one? And if so, can you traceroute to the address where the connection attempt is originating?
Natting is obviously involved on this end and if the incoming ssh session is originating thru a nat then if the response packet doesn't have as a source what the original destination was the nat on the ssh end won't be able to figure where the packet should go.
On Tue, Nov 11, 2014 at 12:55 PM, Steve Clark sclark@netwolves.com wrote:
On 11/11/2014 12:44 PM, Les Mikesell wrote:
On Tue, Nov 11, 2014 at 11:32 AM, Frank Cox theatre@melvilletheatre.com wrote:
On Tue, 11 Nov 2014 10:12:58 -0600 Les Mikesell wrote:
I think that is a different scenario, though. Since the subnet addresses are the same for both routers, the OP must only have one NIC
Yes.
Can you tell where the packets are getting lost? Asymmetric routing is supposed to work per the IP design, but Red Hat thinks they know better and breaks it with their default settings: https://access.redhat.com/solutions/53031
However, I thought that only applied to multiple NICs. Can you tell if packets are coming in from the non-default router and the response sent to the default one? And if so, can you traceroute to the address where the connection attempt is originating?
Natting is obviously involved on this end and if the incoming ssh session is originating thru a nat then if the response packet doesn't have as a source what the original destination was the nat on the ssh end won't be able to figure where the packet should go.
That makes sense. The original target of the connection would be the public side of the non-default gateway and it would reach the target via port-forwarding, keeping the public source address. The response would go to the default router which would forward it on, but NAT to its own public address. Then when the response packet gets back to the originating system it won't be associated with the originating socket since it's source IP won't match the initial target. Or maybe the other router drops it because the connection isn't established and the response packet won't have a SYN.
I can't think of a handy fix for this without extra public addresses. If you know a fixed IP address or range that would only be used for this connection (e.g. to connect in and flip the default gateway if the other one is down), you could add a static route for it.
On 11/11/2014 02:15 PM, Les Mikesell wrote:
On Tue, Nov 11, 2014 at 12:55 PM, Steve Clark sclark@netwolves.com wrote:
On 11/11/2014 12:44 PM, Les Mikesell wrote:
On Tue, Nov 11, 2014 at 11:32 AM, Frank Cox theatre@melvilletheatre.com wrote:
On Tue, 11 Nov 2014 10:12:58 -0600 Les Mikesell wrote:
I think that is a different scenario, though. Since the subnet addresses are the same for both routers, the OP must only have one NIC
Yes.
Can you tell where the packets are getting lost? Asymmetric routing is supposed to work per the IP design, but Red Hat thinks they know better and breaks it with their default settings: https://access.redhat.com/solutions/53031
However, I thought that only applied to multiple NICs. Can you tell if packets are coming in from the non-default router and the response sent to the default one? And if so, can you traceroute to the address where the connection attempt is originating?
Natting is obviously involved on this end and if the incoming ssh session is originating thru a nat then if the response packet doesn't have as a source what the original destination was the nat on the ssh end won't be able to figure where the packet should go.
That makes sense. The original target of the connection would be the public side of the non-default gateway and it would reach the target via port-forwarding, keeping the public source address. The response would go to the default router which would forward it on, but NAT to its own public address. Then when the response packet gets back to the originating system it won't be associated with the originating socket since it's source IP won't match the initial target. Or maybe the other router drops it because the connection isn't established and the response packet won't have a SYN.
I can't think of a handy fix for this without extra public addresses. If you know a fixed IP address or range that would only be used for this connection (e.g. to connect in and flip the default gateway if the other one is down), you could add a static route for it.
Buy second NIC and then the original script Jack Baily provided would work.
On 11/11/2014 2:27 PM, Steve Clark wrote:
Buy second NIC and then the original script Jack Baily provided would work.
I'm outside my area of expertise here, but is there a reason you couldn't fake a second network card by assigning two IP addresses to the one interface?
I recall that the OP had two routers on opposite ends of the same subnet. If each router used its own subnet and everything was connected by a hub instead of a switch, then wouldn't the server know which way the packets needed to go out? Or a switch that knows VLANs, but that might be needlessly complex.
I realize that means installing a hub instead of a second network card, so I'm just asking for my own edification.
On Tue, Nov 11, 2014 at 5:08 PM, Chris Beattie cbeattie@geninfo.com wrote:
On 11/11/2014 2:27 PM, Steve Clark wrote:
Buy second NIC and then the original script Jack Baily provided would work.
I'm outside my area of expertise here, but is there a reason you couldn't fake a second network card by assigning two IP addresses to the one interface?
I recall that the OP had two routers on opposite ends of the same subnet. If each router used its own subnet and everything was connected by a hub instead of a switch, then wouldn't the server know which way the packets needed to go out? Or a switch that knows VLANs, but that might be needlessly complex.
I realize that means installing a hub instead of a second network card, so I'm just asking for my own edification.
There's no difference between a hub and switch with respect to routing. It might be possible to do something with a 2nd ip address in the same subnet used as the target of the port-forwarding from the other router along with policy based routing to make packets with that source ip take the other route. But that would introduce complications for normal outbound traffic. It may depend on the point of having the 2nd connection. Normally cable is so much faster than dls that you would always prefer it unless it was down. If the dsl is just for emergency inbound use you might run a VM configured with the other gateway as the default - maybe even set up openvpn there for fairly transparent access to the rest of the LAN.
On 11/11/2014 23:43, Les Mikesell wrote:
On Tue, Nov 11, 2014 at 5:08 PM, Chris Beattie cbeattie@geninfo.com wrote:
On 11/11/2014 2:27 PM, Steve Clark wrote:
Buy second NIC and then the original script Jack Baily provided would work.
I'm outside my area of expertise here, but is there a reason you couldn't fake a second network card by assigning two IP addresses to the one interface?
I recall that the OP had two routers on opposite ends of the same subnet. If each router used its own subnet and everything was connected by a hub instead of a switch, then wouldn't the server know which way the packets needed to go out? Or a switch that knows VLANs, but that might be needlessly complex.
I realize that means installing a hub instead of a second network card, so I'm just asking for my own edification.
There's no difference between a hub and switch with respect to routing. It might be possible to do something with a 2nd ip address in the same subnet used as the target of the port-forwarding from the other router along with policy based routing to make packets with that source ip take the other route. But that would introduce complications for normal outbound traffic. It may depend on the point of having the 2nd connection. Normally cable is so much faster than dls that you would always prefer it unless it was down. If the dsl is just for emergency inbound use you might run a VM configured with the other gateway as the default - maybe even set up openvpn there for fairly transparent access to the rest of the LAN.
Surely the easiest thing would be to setup a jump host. Essentially, 1 or 2 servers, if you want resiliency, which you can SSH on to from the internet, and then from there access the rest of the network. This gives the benefit of reducing the number of servers that have SSH exposed.
Tris
************************************************************* This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify postmaster@bgfl.org
The views expressed within this email are those of the individual, and not necessarily those of the organisation *************************************************************