Printable View
Without much more in depth info, I doubt anyone online will be able to fix it for you, thus before assuming it must be replaced, I would suggest two things:
1) Is the firmware up to date?
2) Is there anyone you can get to review everything with you? Frequently I've found a second set of eyes can spot very simple problems. :)
An excellent piece of advice.Quote:
Is there anyone you can get to review everything with you? Frequently I've found a second set of eyes can spot very simple problems.
I have seen (and been) techs and mechs going round and round on a problem, and some smart a$$ secretary come in and say "hey you guys want this plugged in ?" (over simplified and no disrespct to any secratary meant)
Hey Hey,
If there's no one there to assist you in looking over the setup... could you possible post a sanitized version of the config.... it may be something obscure burried deep inside....
Peace,
HT
[QUOTE]Without much more in depth info[/QUOT
Ipse Dixit
We all live in Shangri La don't we?
:D
OK... It's fixed.....
Oh, you wanna know what the problem was???? You would.... :rolleyes:
I'm not sure I understand this myself but I'll try to give the relevant detail and see if someone can explain why the router was screwing up.
History:
This router was originally set up by my ISP owner some 6-7 years ago when I had a T1 from the net and another to our only other office. It was set as the default gateway for the local network but it had a default gateway of the firewall. Hence, all traffic that was not local was sent to it to decide what to do with. If the traffic was for the other office it would be appropriately routed, if it wasn't it was routed to the firewall to determine what to do with it. The firewall's default gateway was the border router. I never changed that scheme since it worked just fine until the other day.
Example of issue:
Sat at my workstation on the same physical network as this router _and_ the firewall and the firewall having the route to aa.bbb.ccc.0/24 set to go to the remote office I could ping it, term services to it... anything I allow the "southern" firewall to let me do, (it's in the DMZ of the southern firewall so I have to "allow out" tho services I want). But, if I try to go to any address in the aa.0.0.0/8 network from my workstation it would fail.....
The fix:
Standing in the shower... I do my best thinking there.... Don't ask, I don't know!!!! :eek: I wondered about the default gateway and though that before I replace the router I'll see what happens. So I get to work, change my workstations default route to the firewall itself rather then the internal router... Everything functions fine... as it should... So I re-add the route to aa.bbb.ccc.0/24 to the router and ping it.... I works.... I ping random addresses on the aa.0.0.0/8 net and some respond... I tracert random addresses on the aa.0.0.0/8 net and they all tracert out the right way... Hmm... It works!!!!! I go to the DHCP server and change the default gateway to the firewall and test it from some other machines after an ipconfig /release/renew sequence and they all work.... OK.... perfect... It works....
Can anyone explain _why_.... Remember the system worked perfectly before the addition of the route to the router. With the addition of a route to a class C network the tracert to the class C would work perfectly but the whole class A that the class C was a part of ceased working... That's illogical Captain..... Now the default route is changed is all "tickety-boo", (for non-english speakers "tickety-boo" is a good thing.... :D
Any takers?
[Edit]
I dunno.... maybe I am going completely frigging nuts but why did csch's post get negged here?????? That's stupid.... His points were entirely relevant and good advice....
Unfortunately, my attempt to right the wrong was met with "you have to spread.... blah blah blah"....
I don't know who negged him but I have to say that you are a moron... Thanks for contributing....
[/Edit]
Maybe someone has an ax to grind with CSH, I see you made up for it though?
I read your post Tiger and now my head hurts. Then I re-read it. The only thing I can think of and I am very tired, is there was no route built to allow packets back to you through the original default gateway? You would have to run debug on the router to find that out. I'll shut up now because I am clueless and have to draw it on paper. :confused:
Of course. :)Quote:
Originally posted here by Tiger Shark
OK... It's fixed.....
Oh, you wanna know what the problem was???? You would.... :rolleyes:
I think I have the issue digested enough to come up with a relatively educated guess -- but no guarantees. It might be the order the routes were in. Let's use your example and assume aa = 10, bb = 20 cc = 30.Quote:
Can anyone explain _why_.... Remember the system worked perfectly before the addition of the route to the router. With the addition of a route to a class C network the tracert to the class C would work perfectly but the whole class A that the class C was a part of ceased working... That's illogical Captain..... Now the default route is changed is all "tickety-boo", (for non-english speakers "tickety-boo" is a good thing....
Any takers?
Originally, you had two networks:
A: 10.0.0.0 /8
B: 10.20.30.0 /24
Okay, so traffic hits the router destined for 10.20.30.40, a valid host on network B.
However, the router scans down its list and sees that the traffic is a valid host on network A (listed first), and instead forwards it there.
Now, let's say you reset it all and fixed it. You end up with:
B: 10.20.30.0 /24
A: 10.0.0.0 /8
Same scenario, traffic comes in for 10.20.30.40, but this time it scans down the routes list and sees it's valid for network B, and routes it properly.
Another scenario I came up with is that because the routes conflict it might break one of them (perhaps the original route). Which I'd suggest depends wholely on my interpretation of what you've written. 'Tis quite complicated a situation.
You really don't want those two networks to be "on the same network". You should probably look into subnetting that network. Even breaking it in two -- 10.64.0.0/10 and 10.128.0.0/10 would be sufficient. Of course, that suggestion comes not knowing how many hosts you have on either LAN. :)
Just someone's childish response hitting that post of mine, don't worry about it.Quote:
I dunno.... maybe I am going completely frigging nuts but why did csch's post get negged here?????? That's stupid.... His points were entirely relevant and good advice....
Road:
I didn't "fix" it.... I couldn't without running around giving undeserved pos's to people...
As to your head hurting..... Imagine my head.... I know it was right.... I know that the change of default gateway _shouldn't_ matter because the routes on both the router and the firewall were correct, (the packets shouldn't have reached the firewall if they matched the route on the default gateway, which they did), but they still failed with a "destination host cannot be reached" for a whole A class when the route on the router was clearly a C class..... Do you have some _good_ Tynelol.... 'cos mine still doesn't seem to help..... ;)
The router is internal, (behind the firewall)... It just serves the other networks I have... But it was set as the default gateway because the _expectation_ is/was that most traffic would remain internal to the network..... If it wasn't then it was sent to the firewall that had a default route that left my network for the "big wide world"....
I'm still not understanding _why_ the change of gateway makes it all work... but I'm going to sit with my sweetie and forget it until tomorrow...... :D
csch:
That's a fair go I think... The problem I have is that when I added the route the router itself orders them.
To clarify a little on my network.....
Internet -> Border router 1 -> firewall 1 -> internal network 1 -> Router in question -> T1 -> Internal second network -> T1 ->Internal third network -> Firewall 2 -> Border router 2 - Internet.
There are other networks attached by T1's at varying locations but aren't relevant to the issue.
Border router 1: Ser0 IP:- Public on 207.0.x.0 network, Eth0:- Public IP on 207.0.y.0 network.
Firewall 1: Drop in config on same network as Eth0 on border router 1. Secondary IP:- Private network 192.168.3.4
Internal network 1: 192.168.3.0/24
Router in question: Eth0 IP 192.168.3.1 Ser0: 192.168.2.9 255.255.255.252
Internal second network: Ser0: 192.168.2.10 255.255.255.252 Ser1: 192.168.2.13 255.255.255.252 Eth0: 192.168.30.1
Internal Third Network: Ser0: 192.168.2.14 255.255.255.252 Eth0: 192.168.50.1
Firewall 2: Drop in config on 63.x.x.x Secondary IP: 192.168.50.2
Border router 2: Eth0: IP on same 63.0.0.0 as firewall 2 Ser0 on 63.0.0.0 network
Hope that's clearer....
Now, the issue was that there is a new DNS/SMTP server in the DMZ of firewall 2. (Never had one there before so this wasn't an issue). I don't want to open a port on the outside of firewall 2 so I can administer it and also I need it to be able to pass mail all the way up to the exchange server on internal network 1.... So I need to reroute, lets say, 63.1.1.0/24 down through the other two internal networks to firewall 2 which is on that network. There was no issue for internal networks 2 and 3 because their default gateways pointed down to firewall 2 anyway but the router in question had a default gateway of firewall 1 and the internal network 1 used the router in question as their default gateway.
So, logically I add the following route to the router in question:-
ip route 63.1.1.0 255.255.255.0 192.168.2.10, (the internal network 2)
and to Firewall 1
I add the route:-
63.1.1.0/24 -> 192.168.3.1, (the router in question)
Should work fine, once it reached internal network 2 it will be sent on outbound through firewall 2 anyway. A tracert indicates that it does, indeed, route down through the other two networks, mail flows, I can term services to the new server and everything seems fine...... Then I get the phone call..... Being the good admin I am I know that i just changed something and therefore that is the first thing I looked at. I determined that the remote address that was now not cooperating with the users was at, let's say, 63.12.76.10.... So I ping it and get nothing.... OK, fair... I tracert it and the router in question says "destination host is unreachable".... :eek: .... So I tracert 63.1.1.x, (the new server), and it runs perfectly..... I remove the route from the router in question and, obviously, I can no longer see the new server but the remote address at 63.12.76.10 now tracert's just fine out through firewall 1 like it should..... replace the route and the new server is back up but the remote IP is unreachable.
My workstation uses the router in question as it's default gateway. I change it to the secondary IP of firewall 1 and both the new server _and_ the remote IP function just fine.....
I dunno... I still don't see why that change makes a difference. With my DG set as the router in question a packet for the remote IP should go:-
1: My NIC
2. The router in question
3. Firewall 1
4. Border Router 1
5. The internet
A packet for the new server should go:-
1. My NIC
2. The router in question
3. Internal network 2
4. and so on...
The gateway _shouldn't have made a difference.... But it made a really big one.... :(
Last night while downing a Canadian beer with my cat, I was thinking Pix Firewall conduits. I know that's not an answer more a direction but I didn't drink enough beer although hopped enlightenment was close at hand. I printed this out for weekend study.