This was most likely due to the gratuitous arps when the machines booted. It's possible that the router(s) cached them and issued ICMP redirects. I can see how it could happen and yep, you're correct, it'd work like ass ;)
--Bill On 12/11/06, mOjO <[EMAIL PROTECTED]> wrote:
either that or its the switch? ever run two completely different subnets (and networks) on the same unmanaged switch? (of course this begs the question WHY?) but well... it has some interesting effects. of course it works fine for each subnet within themselves but when trying to contact one network from the other things get interesting. I did not set this up but i walked into a client that had this type of scenario: 192.168.1.0/24 dhcp clients, servers, etc. <--> Multiple Unmanaged 10/100 switches (Linksys or something) <--> Cisco router (default gw) <--> T1 to HQ & Internet -and- 10.1.1.0/24 static clients <--> the same switches as above <--> different router to another T1 to an unrelated network the client pc's on the 10.x were pointing to the 10.x router for their gw. neither router new anything about the other one (no static routes, no dynamic protocols). theoretically this shouldn't really work when trying to pass data from a PC on one subnet to a PC on the other. but actually it does... kinda. ping worked. and it wasn't within the scope of my work to fix this mess but I had to access one from the other and found RDP worked like crap but for some reason VNC worked better and allowed me to control the PCs in the second network from the first. since this was definitely not an arp-cache thing on the PCs themselves it had to be the switch seeing IP's and sending the data out the right port. why some stuff worked ok and others didn't might make an interesting point of research for the curious. of course why anyone would want to setup networks like that is beyond me but i've always been curious how in the heck that worked at all... Bill Marquette wrote: > Probably those machines had 192.168.125.65's mac address still cached. > Knowing what the MAC was, they didn't need to do an arp lookup for > their default gateway to send the traffic on. Expect those machines > to stop working before too long ;-P > > --Bill > > On 12/9/06, Jonathan Horne <[EMAIL PROTECTED]> wrote: >> i previously had 2 sites, both with pfsense firewalls. >> >> site a - 192.168.125.0/26 >> site b - 192.168.125.64/26 >> >> i recently did away with site a, and since those ips were no longer >> in use, i >> decided to change my site b from a /26 to a /25. so i started with the >> pfsense box. it ip was previously 192.168.125.65, and i changed it to >> 192.168.125.1. saved changes. >> >> now, all the hosts at site b are also on the same 192.168.125.64/26, >> with ips >> between x.x.x.65-127. theoretically, with site a gone, they should >> be able >> to ping nothing below 64, since they are off their network. but, as >> soon as >> the pfsense interface was back up, hosts that had ips betwen >> x.x.x.65-127 >> were already able to ping 192.168.125.1, and any other hosts on the >> internet >> (even tho the gateway on their network was no longer there! .65 was >> unpingable). >> >> uh, i thought i understood the basic concepts of subnetting, and if i >> had it >> all wrong, then why was my previous vpn between site b and a working >> perfectly? or is there some devilry or trickery in the way bsd does >> its tcp? >> >> totally confused, >> jonathan >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: [EMAIL PROTECTED] >> For additional commands, e-mail: [EMAIL PROTECTED] >> >> > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
