On Tue, Nov 11, 2014 at 12:55 PM, Steve Clark <sclark@xxxxxxxxxxxxx> wrote:
> On 11/11/2014 12:44 PM, Les Mikesell wrote:
>>
>> On Tue, Nov 11, 2014 at 11:32 AM, Frank Cox <theatre@xxxxxxxxxxxxxxxxxxx>
>> 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.
--
Les Mikesell
lesmikesell@xxxxxxxxx
_______________________________________________
CentOS mailing list
CentOS@xxxxxxxxxx
http://lists.centos.org/mailman/listinfo/centos
