«

I'm having a routing problem with our 515E and have talked to Cisco
about this problem this morning. Hoping that somebody can help me
with this because Cisco wants me to make changes to a router etc. that
hasn't had to change in 5 years... They want me to route all
traffic to 192.192.61.254 and then default route it back to
192.192.61.224 which I really am not fond of...

Currently, we have a Cisco 806 servicing our internal network reaching
the outside world. Our internal subnet is 192.192.61.0/24 with the
gateway being 192.192.61.224. We also have another subnet of
192.192.50.0/24 that is reachable via a gateway of 192.192.61.254.

On the existing router I simply added an ip route statement to route
192.192.50.0/24 to 192.192.61.254 and it works fine. With the PIX it
doesn't work.... I can't reach 192.192.50.220 which is the AS/400 at
another site. It doesn't ping or nothing...

The following is my config.. can anyone tell me why I'm having
issues?? Thanks in advance.

PIX Version 6.2(2)
nameif ethernet0 outside security0
nameif ethernet1 inside security100
nameif ethernet2 intf2 security10
enable password XXXXXXXXXXXXXXXX encrypted
passwd XXXXXXXXXXXXXXXXX encrypted
hostname fw
domain-name nexicom.net
clock timezone EST -5
clock summer-time EDT recurring
fixup protocol ftp 21
fixup protocol http 80
fixup protocol h323 h225 1720
fixup protocol h323 ras 1718-1719
fixup protocol ils 389
fixup protocol rsh 514
fixup protocol rtsp 554
fixup protocol smtp 25
fixup protocol sqlnet 1521
fixup protocol sip 5060
fixup protocol skinny 2000
names
access-list 100 permit icmp any any time-exceeded
access-list 100 permit icmp any any unreachable
pager lines 24
logging on
logging trap informational
logging facility 23
logging queue 0
logging host outside XXXXXXXXXXXXx 6/1470
interface ethernet0 100full
interface ethernet1 100full
interface ethernet2 auto shutdown
mtu outside 1500
mtu inside 1500
mtu intf2 1500
ip address outside public.ip.here. 255.255.255.0
ip address inside 192.192.61.224 255.255.255.0
ip address intf2 127.0.0.1 255.255.255.255
ip audit info action alarm
ip audit attack action alarm
pdm history enable
nat (inside) 10 0.0.0.0 0.0.0.0 0 0
access-group 100 in interface outside
route outside 0.0.0.0 0.0.0.0 216.168.96.1 1
route inside 192.192.50.0 255.255.255.0 192.192.61.254 1
timeout xlate 3:00:00
timeout conn 1:00:00 half-closed 0:10:00 udp 0:02:00 rpc 0:10:00 h323
0:05:00 sip 0:30:00 sip_media 0:02:00
timeout uauth 0:05:00 absolute
aaa-server TACACS+ protocol tacacs+
aaa-server RADIUS protocol radius
aaa-server LOCAL protocol local
aaa authentication telnet console LOCAL
aaa authentication ssh console LOCAL
ntp server 130.126.24.44 source outside prefer
http server enable
http 192.192.61.0 255.255.255.0 inside
snmp-server host outside xxx.xxx.xxx.xxx
snmp-server location Nexicom CO
snmp-server contact Paul Stewart
snmp-server community blahblahblah
no snmp-server enable traps
floodguard enable
sysopt noproxyarp outside
sysopt noproxyarp inside
no sysopt route dnat
telnet timeout 5
ssh 192.192.61.0 255.255.255.0 inside
ssh timeout 5
dhcpd address 192.192.61.1-192.192.61.99 inside
dhcpd dns 216.168.96.10 216.168.96.13
dhcpd lease 3600
dhcpd ping_timeout 750
dhcpd domain nexicom.net
dhcpd enable inside
username admin password XXXXXXXXXXXXXXXXXX encrypted privilege 15
terminal width 80

In article < >,
Paul Stewart <> wrote:
:I'm having a routing problem with our 515E and have talked to Cisco
:about this problem this morning. Hoping that somebody can help me
:with this because Cisco wants me to make changes to a router etc. that
:hasn't had to change in 5 years... They want me to route all
:traffic to 192.192.61.254 and then default route it back to
:192.192.61.224 which I really am not fond of...

:Currently, we have a Cisco 806 servicing our internal network reaching
:the outside world. Our internal subnet is 192.192.61.0/24 with the
:gateway being 192.192.61.224. We also have another subnet of
:192.192.50.0/24 that is reachable via a gateway of 192.192.61.254.

:On the existing router I simply added an ip route statement to route
:192.192.50.0/24 to 192.192.61.254 and it works fine. With the PIX it
:doesn't work.... I can't reach 192.192.50.220 which is the AS/400 at
:another site. It doesn't ping or nothing...

I am not sure I understand your situation correctly. What I think you
are trying to explain is that you have two internal networks,
192.192.61.0/24 and 192.192.50.0/24, that your hosts on 192.192.61.0/24
are using the PIX inside address as their default route, that your
hosts on 192.192.61.0/24 do NOT have a specific route to
192.192.50.0/24 via 192.192.61.254, and that you want your hosts on
192.192.61.0/24 to be able to reach 192.192.50.0/24 by sending the
packets to the PIX inside interface and have the PIX route the packets
back into the inside network via the gateway at 192.192.61.254 .

If that is an accurate description of the situation, then you cannot
proceed in this way. The PIX will NEVER route packets back to the same
[logical] interface that packets came in on. It! Can! Not! Be! Done! Period!


If you have multiple internal subnets and you want the subnets to
be able to reach each other, then up through PIX 6.2, you must use
an internal router for the cross-subnet traffic. You can do that by
sending all host traffic to the internal router [the configuration
Cisco has suggested to you], or you can do that by adding a specific
route on to each of the hosts. I am not familiar enough with Windows
boxes to say anything about how you would add a route on to them.
[It's a relatively easy task on any UNIX-based system.]

With PIX 6.3(1), there is an additional option that becomes
possible [but not on PIX 501, PIX 506, or PIX 506E.] PIX 6.3(1)
supports logical interfaces, which are multiple 802.1Q VLANs
on a single physical interface. If the connection between your
PIX and your hosts happens to be via an 802.1Q aware switch,
then you could upgrade the PIX to 6.3(1), and then create
a virtual interface on the inside physical interface,
assigning an IP address in the 192.191.50.0/24 range to the
virtual interface, assigning a security level to the interface,
and creating all appropriate access-list and 'static' entries
to regulate the traffic flow between the two subnets; then you
would tell the switch to change from "access" to "trunk" for that
physical connection.

If, though, you are prepared to go through all that trouble, then
even in 6.2(2), you might as well just use your third physical
interface, and make the PIX the effective router between the two
subnets. Whether you use a physical or virtual interface, you would
have to cut out the internal routing between the two subnets in
order to prevent loops and asymmetric flows; 6.3(1) merely allows
you to do so with fewer physical interfaces.
--
Are we *there* yet??

G,day,

first thing first, is this your network??


internet-------806-------pix-224------192.192.61.0/24--------
|
|
192.192.61.254
|
|
--------------192.192.50.0/24--------



are there any routers in the network eg, it seems your using the pix
as your default router 192.192.61.224, is 192.192.61.254.0 a router or
a host of somesort???. If i understand correctly using the pix as a
router you are trying to ping hosts FROM 61.x net to 50.X net and it
does not work. This will never work because the pix 101 "the pix is
not a router", it does routing through interfaces, but due to its
paranoid nature it see's the traffic originate from the interface it
want to send back out on and drops the packet. there is no way around
this as walter stated. your most simples way around it is ciscos
advise. make 254 your default gateway and add a defualt route pointing
back to the pix.

Mike


(Paul Stewart) wrote in message news:<. com>...
> I would like to take a moment to thank you for your wonderful
> explanation. As much as I don't like that answer I have to accept
> it... we don't have a VLAN aware switch on the inside unfortunately
> but I do have another router there currently that we could use.
>
> I think I'll followup on adding static routes to the workstations and
> see where that leads us.. it's only about 5 machines running Windows
> that this whole issue effects....
>
> Unfortunately the gentleman from Cisco didn't explain this issue very
> well to me and since it works fine with a router in there currently, I
> couldn't understand why a much more complicated and much much more
> expensive box like the PIX wouldn't do it... but as we know, routers
> are not security devices and let all of us break rules once in a
> while..heheehe..
>
> Take care,
>
> Paul
>
> (Walter Roberson) wrote in message news:<bec82t$ept$>...
> > In article < >,
> > Paul Stewart <> wrote:
> > :I'm having a routing problem with our 515E and have talked to Cisco
> > :about this problem this morning. Hoping that somebody can help me
> > :with this because Cisco wants me to make changes to a router etc. that
> > :hasn't had to change in 5 years... They want me to route all
> > :traffic to 192.192.61.254 and then default route it back to
> > :192.192.61.224 which I really am not fond of...
>
> > :Currently, we have a Cisco 806 servicing our internal network reaching
> > :the outside world. Our internal subnet is 192.192.61.0/24 with the
> > :gateway being 192.192.61.224. We also have another subnet of
> > :192.192.50.0/24 that is reachable via a gateway of 192.192.61.254.
>
> > :On the existing router I simply added an ip route statement to route
> > :192.192.50.0/24 to 192.192.61.254 and it works fine. With the PIX it
> > :doesn't work.... I can't reach 192.192.50.220 which is the AS/400 at
> > :another site. It doesn't ping or nothing...
> >
> > I am not sure I understand your situation correctly. What I think you
> > are trying to explain is that you have two internal networks,
> > 192.192.61.0/24 and 192.192.50.0/24, that your hosts on 192.192.61.0/24
> > are using the PIX inside address as their default route, that your
> > hosts on 192.192.61.0/24 do NOT have a specific route to
> > 192.192.50.0/24 via 192.192.61.254, and that you want your hosts on
> > 192.192.61.0/24 to be able to reach 192.192.50.0/24 by sending the
> > packets to the PIX inside interface and have the PIX route the packets
> > back into the inside network via the gateway at 192.192.61.254 .
> >
> > If that is an accurate description of the situation, then you cannot
> > proceed in this way. The PIX will NEVER route packets back to the same
> > [logical] interface that packets came in on. It! Can! Not! Be! Done! Period!
> >
> >
> > If you have multiple internal subnets and you want the subnets to
> > be able to reach each other, then up through PIX 6.2, you must use
> > an internal router for the cross-subnet traffic. You can do that by
> > sending all host traffic to the internal router [the configuration
> > Cisco has suggested to you], or you can do that by adding a specific
> > route on to each of the hosts. I am not familiar enough with Windows
> > boxes to say anything about how you would add a route on to them.
> > [It's a relatively easy task on any UNIX-based system.]
> >
> > With PIX 6.3(1), there is an additional option that becomes
> > possible [but not on PIX 501, PIX 506, or PIX 506E.] PIX 6.3(1)
> > supports logical interfaces, which are multiple 802.1Q VLANs
> > on a single physical interface. If the connection between your
> > PIX and your hosts happens to be via an 802.1Q aware switch,
> > then you could upgrade the PIX to 6.3(1), and then create
> > a virtual interface on the inside physical interface,
> > assigning an IP address in the 192.191.50.0/24 range to the
> > virtual interface, assigning a security level to the interface,
> > and creating all appropriate access-list and 'static' entries
> > to regulate the traffic flow between the two subnets; then you
> > would tell the switch to change from "access" to "trunk" for that
> > physical connection.
> >
> > If, though, you are prepared to go through all that trouble, then
> > even in 6.2(2), you might as well just use your third physical
> > interface, and make the PIX the effective router between the two
> > subnets. Whether you use a physical or virtual interface, you would
> > have to cut out the internal routing between the two subnets in
> > order to prevent loops and asymmetric flows; 6.3(1) merely allows
> > you to do so with fewer physical interfaces.