Re: Odd routing issue

Hello Lee,

What hosts OS are you running? Did you check the redirect routes?

Linux: ip route list cache
Win: route print

Im wondering if the host received ICMP redirect message corectly. If the 
routes are correct, I would do a bit more tracing even on the interface 
of FW1.

Best regards

~ Jakob

On 27.08.2013 15:56, wrote Lee Sharp:
> On 08/27/2013 02:42 AM, Jack wrote:
>> Hello Lee,
>>
>> (I think there is a typo in the network diagram, 192.168.42.2 should be
>> 192.168.40.2 as far as I understand)
>
> Doh!  Don't do diagrams while eating dinner!  You are correct.
>
>> I would design that in that way: http://snag.gy/nzJz6.jpg
>
> Unfortunately, the box is only 4 ports...
>
>> but anyway,
>>
>> You have kind a Triangle- Route which i think is suboptimal
>>
>> Ping starting from 192.168.40.x
>> Query:
>> 192.168.40.x -> 192.168.40.1(ICMP redirect to 192.168.40.2) ->
>> 192.168.40.2 -> 192.168.43.x
>> Response:
>> 192.168.43.x -> 192.168.40.2 -> 192.168.40.x
>
> That is exactly the path.  The odd parts is that any traffic can get 
> to both sides, but traffic from 43.x can not get back to 43.x...
>
>> I thinke there is one firewall or host having trouble with MAC address
>> learning:
>>
>> What MACs are learned on Host 192.168.40.x when the ping doesn't work
>> from 192.168.43.x to 192.168.40.x?
>> What MACs are learned on Host 192.168.40.x when the ping magically work
>> from 192.168.43.x to 192.168.40.x?
>>
>> And the same on FW 2 Interface 192.168.40.2?
>
> But it should never use MAC.  I see a ICMP echo coming out of a the 
> device being pinged on 40.x going to 192.168.43.2, so it would go to 
> the default route, 192.168.40.1, which has the static route to 
> 192.168.40.2...  Everything is correct, but it just doesn't work. :)  
> Argh!
>
>             Lee
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [email protected]
> For additional commands, e-mail: [email protected]
>