Routing Buffs, I emplore you...!
Discussion
Right,
Got a wierd one here...
Short story:
Two locations, connected by Manual IPSec VPN. VPN works lovely, and everything can see eachother hunky dory...except...
We have two subnets in Bristol
212.134.82.192/26
192.168.1.0/24
Our P'Boro office is 192.168.4.0/24
All fine and dandy...
Except 192.168.1.0/24 machines cannot ping or communicate with CERTAIN IP's on the 192.168.4.0/24 subnet.
They can ping most things except .2 and .5, however I've turned on the 'success' logging on the firewall and the firewall is letting the ping traffic through the firewall...
Now then, how can I add a route to get me over my firewall and to the specific IP - if this is what I need to do?
Got a wierd one here...
Short story:
Two locations, connected by Manual IPSec VPN. VPN works lovely, and everything can see eachother hunky dory...except...
We have two subnets in Bristol
212.134.82.192/26
192.168.1.0/24
Our P'Boro office is 192.168.4.0/24
All fine and dandy...
Except 192.168.1.0/24 machines cannot ping or communicate with CERTAIN IP's on the 192.168.4.0/24 subnet.
They can ping most things except .2 and .5, however I've turned on the 'success' logging on the firewall and the firewall is letting the ping traffic through the firewall...
Now then, how can I add a route to get me over my firewall and to the specific IP - if this is what I need to do?
Double check the affected machines default GW and subnet mask. I strongly suspect it won't be the routers, as they are working for the majority of machines.
Do a "route print" from the command line and check there aren't any static routes in the problem machines.
I would also check for the existence of any locally installed firewall SW on the affected machines.
That should crack it.
Do a "route print" from the command line and check there aren't any static routes in the problem machines.
I would also check for the existence of any locally installed firewall SW on the affected machines.
That should crack it.
BliarOut said:
Double check the affected machines default GW and subnet mask. I strongly suspect it won't be the routers, as they are working for the majority of machines.
Do a "route print" from the command line and check there aren't any static routes in the problem machines.
I would also check for the existence of any locally installed firewall SW on the affected machines.
That should crack it.
If I give the affected machine a 212.134.82. addy, with the appropriate gateway, they work, but change them back to a 192.168.1.0/24 addy and they fail even if I use the same gateway...
danielson said:
can u ping the other way round from .2/.5
what does a tracert do if you do one to say .2 and one you can ping..does the route change?
Yep, and it's fine...
danielson said:
you sure theres no access lists anything restricting these specific IPs to ICMP stuff?
Shouldn't be, as I've made no change to anything...
neil_cardiff said:
Double check the affected machines default GW and subnet mask. I strongly suspect it won't be the routers, as they are working for the majority of machines.
Do a "route print" from the command line and check there aren't any static routes in the problem machines.
I would also check for the existence of any locally installed firewall SW on the affected machines.
That should crack it.
If I give the affected machine a 212.134.82. addy, with the appropriate gateway, they work, but change them back to a 192.168.1.0/24 addy and they fail even if I use the same gateway...
To just the certain afected machines? (2 & 5 ) In that case, the affected machines have a duff route to the 192.168.1.X network. Bit of tracert use should confirm my suspicions.
The affected machines would have a duff routing to 192.168.4.0/26 
I agree, and I've checked for staic routing, which there is none (shouldn't be anyway, their all standard workstations)...
When I do a tracert I get (bearing in mind that the FW has an additional secondry network configuration of 192.168.1.1 as well as 212.134.82.193 to get over the two subnets):
Tracert hits 192.168.1.1 then Time Out all the way...
I'm stumped, and hence wondering whether I could butcher a static route?
I agree, and I've checked for staic routing, which there is none (shouldn't be anyway, their all standard workstations)...
When I do a tracert I get (bearing in mind that the FW has an additional secondry network configuration of 192.168.1.1 as well as 212.134.82.193 to get over the two subnets):
Tracert hits 192.168.1.1 then Time Out all the way...
I'm stumped, and hence wondering whether I could butcher a static route? neil_cardiff said:
The affected machines would have a duff routing to 192.168.4.0/26
I agree, and I've checked for staic routing, which there is none (shouldn't be anyway, their all standard workstations)...
When I do a tracert I get (bearing in mind that the FW has an additional secondry network configuration of 192.168.1.1 as well as 212.134.82.193 to get over the two subnets):
Tracert hits 192.168.1.1 then Time Out all the way...
192.168.1.0/24 surely?
If I read you problem right, the peterborough machines (192.168.4.2 and 192.168.4.5) don't reply to pings from 192.168.1.X. In that case, your packets are arriving in Peterborough, but getting lost on the way back. Again, if I'm reading it right, the problem is in Peterborough, not Cardiff.
I'm in Peterborough, so I'll keep my eyes out for any suspicious looking piles of ones and zero's and pop them in the post for you
BliarOut said:
The affected machines would have a duff routing to 192.168.4.0/26
I agree, and I've checked for staic routing, which there is none (shouldn't be anyway, their all standard workstations)...
When I do a tracert I get (bearing in mind that the FW has an additional secondry network configuration of 192.168.1.1 as well as 212.134.82.193 to get over the two subnets):
Tracert hits 192.168.1.1 then Time Out all the way...
192.168.1.0/24 surely?
If I read you problem right, the peterborough machines (192.168.4.2 and 192.168.4.5) don't reply to pings from 192.168.1.X. In that case, your packets are arriving in Peterborough, but getting lost on the way back. Again, if I'm reading it right, the problem is in Peterborough, not Cardiff.
I'm in Peterborough, so I'll keep my eyes out for any suspicious looking piles of ones and zero's and pop them in the post for you
They're lonely ones, so if you could give them a cuddle before sending them, that'd be great... You may well have just hit the nail on the head there, as we have an additional fireall, which the P'boro machines gateway through. 192.168.4.2 should have had a static route that basicly routed out via that firewall...it may have lost it. 192.168.4.5 is a new machine that probably has never had the route added so yes, you're right
I'll report back in a mo...
Ta!
Neil
>> Edited by neil_cardiff on Thursday 8th December 15:05
Gassing Station | Computers, Gadgets & Stuff | Top of Page | What's New | My Stuff