On 11/11/2014 02:15 PM, Les Mikesell wrote:
On Tue, Nov 11, 2014 at 12:55 PM, Steve Clark <scl...@netwolves.com> wrote:
On 11/11/2014 12:44 PM, Les Mikesell wrote:
On Tue, Nov 11, 2014 at 11:32 AM, Frank Cox <thea...@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.
--
Stephen Clark
*NetWolves Managed Services, LLC.*
Director of Technology
Phone: 813-579-3200
Fax: 813-882-0209
Email: steve.cl...@netwolves.com
http://www.netwolves.com
_______________________________________________
CentOS mailing list
CentOS@centos.org
http://lists.centos.org/mailman/listinfo/centos
