mrsmileyns
asked on
Cisco 2600 - make packets appear as from original host
I am not sure what this is called or if it is even possible - but here is my situation - I have a Win2K network - Cisco 3500 switch and a 2600 router - primary WAN connectivity is a point to point T1 off the 2600 back to the home office. There is also a Watchguard Firbox connected to an internet T1 that is VPN back to the home office. This is not usually in use and is to serve as a backup solution. The internal IP of the Cisco is 192.168.10.1 and the internal of the Watchguard is .2 - the gateway for all the PC's and servers is .1 The Cisco has 2 defualt routes - primary is for the WAN, secondary is to the Watchguard at .2 with a metric of 100. When the WAN goes down, the Cisco functions properly...it begins to route packets to the .2 interface of the Watchguard - trouble is, the Watchguard does not like this...all of the traffic is coming from the .1 interface of the Cisco, not directly from the PC's. If I assign the gateway manually to the PC's of .2 it works. I have experimented with alternate gateways at the Windows level, and I don't like how it works. So, my question is this...is there a way to make the Cisco 2600 allow the packets to pass right through it to the Watchguard and not appened any type of header or whatever is actually occuring? Is there a way to make the Watchguard not see the Cisco per say and have it think the incoming packets came directly from the PC's when the Cisco starts routing the packets to it beacuse the WAN is down? I hope that made sense.
ASKER
well...i don't see no icmp redirect in the config...but i am not sure how to debug icmp - i tried typing in the command debug icmp - and it wouldn't take it
Oops! Sorry. It's "debug ip icmp"
If it's not disabled, then it should be working.
Is the MAC address of the Cisco's .1 interface blocked by the firewall?
-Don
If it's not disabled, then it should be working.
Is the MAC address of the Cisco's .1 interface blocked by the firewall?
-Don
Look for "no ip redirects" on the Ethernet interface.
Try adding "ip redirects"
router(config)# interface Ethernet 0/0
router(config-if)#ip redirects
Try adding "ip redirects"
router(config)# interface Ethernet 0/0
router(config-if)#ip redirects
ASKER
nope - no MAC addresses blocked at the firewall - I can ping the firewall from the router and from the workstations as well - but the firewall is having a problem routing the packets since they are all coming from the router, not directly from the PC's via the switch
Have you tried to clear the arp cache on the 2600?
If it's holding arp entries for the remote network, you will have to wait until they time out..
If it's holding arp entries for the remote network, you will have to wait until they time out..
ASKER
ip redirects? what exactly does that do?
Ip redirects sends a packet to the originating station that says "that route doesn't go through me, it's actually over -- there, so re-direct your packets to that gateway". Windows 2000 and XP boxes (as well as others, but I'm not sure which ones) respond to that redirect packet and add a temporary static route entry pointing to the new gateway.
ASKER
that might be...might be exaclty what i need - i have been working on this for a while...this silly solution was half in place when i got here and now they want me to make it work - if it were me i wouldn't have done this this way - i probably would have used BGP to set up the failover...but anyway...maybe this will help
Are both FE interfaces on the 2600 in use? If not, you could use the second one as a route (on a different range) to the WatchGuard, with failover happening on the 2600 invisibly to the clients....
ASKER
i tried that - set up a .11 network on the spare ethernet on the 2600 - still didn't work - the Cisco sends them to the Watchguard at failover - that part works - but the Watchguard still gets all confused - to top it off the Watchguard is managed by an outside vendor - so I need to get them to make any changes :(
ASKER
i enabled IP redirects - actually it was already enabled - I didn't realize - still no dice - I beleive I have reached certain limitations in the Watchguard - it is good for what it is...it is not a bad product, but this situation, the way my boss envisioned it done...requires a different solution or device
This is purely just for my own info..I have never worked with a PIX....but do you think, if the Watchguard were not a Watchguard, but a PIX...would this work? I have to imagine the PIX is much more flexible and versatile. And much more like a fully featured router.
This is purely just for my own info..I have never worked with a PIX....but do you think, if the Watchguard were not a Watchguard, but a PIX...would this work? I have to imagine the PIX is much more flexible and versatile. And much more like a fully featured router.
>PIX is much more flexible and versatile.
I have to agree on that..
>And much more like a fully featured router.
Not really. It won't do things like send redirects, but it will do what you are trying to do. If it was the other way 'round, with the PIX as the primary link and a router as a secondary/fallback gateway, then it would not work.
>the Watchguard is managed by an outside vendor
It may be a limitation on the expertise of this "outside vendor"...
I have to agree on that..
>And much more like a fully featured router.
Not really. It won't do things like send redirects, but it will do what you are trying to do. If it was the other way 'round, with the PIX as the primary link and a router as a secondary/fallback gateway, then it would not work.
>the Watchguard is managed by an outside vendor
It may be a limitation on the expertise of this "outside vendor"...
ASKER CERTIFIED SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
ASKER
You know...it's funny...I came home last night and saw this update. I worked with my vendor last night and we determined that to be the trouble. Packets did not know how to get back over the VPN tunnel when the point to point connection was down...as the point to point is the default route for packets destined for my network at 192.168.10.0. As soon as I removed that route, the packets defualted to the default route which is the Watchguard in my NYC office...connected to the Watchguard on the NJ office...over the tunnel. Hey, I have only been doing this type of work for 3 years...I think I am doing pretty good all things considered :)
I have since suggested a backup plan to my management...although it requires a bit of human intervention...it works...and we don't have to spend any more money to do it. Considering the normal connectivity is 2 point to point T1's connected to 2 seperate WIC's at both locations through seperate providers...I think the backup VPN solution will not be used too often, if ever...hopefully. I think a little human intervention to make it work in exchange for no additional expenditure isn't such a bad tradeoff.
I have since suggested a backup plan to my management...although it requires a bit of human intervention...it works...and we don't have to spend any more money to do it. Considering the normal connectivity is 2 point to point T1's connected to 2 seperate WIC's at both locations through seperate providers...I think the backup VPN solution will not be used too often, if ever...hopefully. I think a little human intervention to make it work in exchange for no additional expenditure isn't such a bad tradeoff.
Can you not alter the routes in the NJ tunnel so that it has a simlar floating static route to NYC? That way things will failover, even if you are enjoying your christmas bonus in tahiti ;)
ASKER
somewhere along the line i decided to leave the same internal IP on the NJ Watchguard 192.168.10.1 as the normal Cisco 2600 IP...default gateway for the LAN - that way I don't have to play with alternate routes etc. I just have to move 1 cable 6 inches from 1 port to another in the event of an outage. My vendor told me the Watchguard really "likes" to get its traffic directly from the PC's, not to the router and then to the Watchguard - that being said...it seemed simple to leave the same IP on the Watchguard and in the event of an outage have it totally take the place of the Cisco, rather than roll to it. I suppose it is ugly, but it seems to work so far.
ASKER
well - I am not sure how to close this question...because the right answer wasn't really based on the initial question - my problem was actually due to a different issue than what the experts were first trying to answer
I guess if it works for you, it works for you! Does the watchguard not protect your Internet connection normally?
I would be worried that a "helpful" collegue spots the firewall being unplugged an puts the cable into it, and so create two instances of the same IP on a network.
Dunno how to close the question, you could just give me all the points ;)
I would be worried that a "helpful" collegue spots the firewall being unplugged an puts the cable into it, and so create two instances of the same IP on a network.
Dunno how to close the question, you could just give me all the points ;)
ASKER
actually...this watchguard is purely backup - we go over a mb pipe to the home office and then out to the internet over a 4.5 mb pipe there - the nature of our business demands all internet browsing be logged, by law - so we have one point of internet connectivity..except for an emergency backup plan
actually, i am the only sys admin at my office...no one else even has access to my server room - my office is small, but its function is vital, and bandwidth requirements fairly high - thus the 3 mb pipe and backup plan
i guess i will give you the points...this was all good info...but your information was correct concerning the return route
actually, i am the only sys admin at my office...no one else even has access to my server room - my office is small, but its function is vital, and bandwidth requirements fairly high - thus the 3 mb pipe and backup plan
i guess i will give you the points...this was all good info...but your information was correct concerning the return route
Check for a "no icmp redirect" in the config.
Maybe try a debug icmp on the Cisco and look for redirects.
-Don