PIX 506E static route problem

Hi all,

My name is Giulian and I'm writing from Italy. I have a problem with PIX 506E 6.3(5).

The outside interface has a public ip The inside interface has a private ip The local lan use address and default gateway is the inside interface ip.

In the inside zone I have a router with ip that is connect with Point-to-Point to another network with address.

I would like to connect with pc of the network through inside router and so I have insert a route static in the pix configuration like:

route inside 1

My problem concern that this configuration doesn't running.... For more security I have try to connect with cross cable to the inside router and I can ping the remote pc of lan.

Any idea? Thanking in advance and sorry for my english.


Reply to
Loading thread data ...

PIX doesn't give ICMP redirect. You have to change your configuration so that the default gateway is the router.

Reply to
Jyri Korhonen

If you add the route manually on the workstation not the pix does it traverse the point to point link? If not then you might have ACL's preventing traffic across the link. The statement you have IMO looks fine.

For example on a windows PC in a command prompt type:

route add MASK


route add -net netmask gw dev eth0


Reply to
George W. Bush

Outside IP Inside IP Outside IP Inside IP


It should work

can you post your config


tfanabe wrote:

Reply to

Where are you starting from when you want to connect to that pc on

10.10.46/24 ? If you are starting from outside, then the route statement you give should be fine, provided that the 10.10.46/24 network is nat'd (for traffic that is outgoing only) or static'd to a public IP if something on 10.10.46/24 is acting as a server [a case that would require appropriate outside ACLs.]

But if you are starting from something on your 10.10.45/24 network and expecting that hosts there will send the packet to the PIX (because it is their default gateway) and that the PIX will forward it over to for transport to 10.10.46/24, then like the other poster said, that is not going to work: the PIX does not send out ICMP redirects and will just drop the packets.

Reply to
Walter Roberson


No it should not . This route is only for packets entering the PIX on the outside interface. It can then be routed on the inside through the gateway mentionned in the statement.Or if you ping from the PIX itself as tfanabe did, it will work.

But if the packet comes from the inside it will not be routed back on the inside. The PIX doesn't allow a packet to leave using the same interface it came from.

The PIX is not a router , unfortunately tfanabe you will need another device to accomplish what you are trying to do.

Reply to

What if we NAT the IPs

mcaissie wrote:

Reply to

There is no point in us answering that question until you answer the question I posed in my response: where are the packets starting from that you are trying to get through to the second subnet?

Repeating what I said before: if the packets are coming from outside, there is no problem. If the packets are coming from inside then there is NO way you are going to be able to get your PIX 506E to pass the traffic back to the same interface.

If the packets are originating "inside", then change the default gateway of all of those hosts to be the IP address of the inside router, so that packets going from inside to the other inside subnet do not pass through the PIX.

If you can't do that for some reason, your only other hope is that you are using an 802.1Q compatible switch and that you implement two "logical interfaces" on the same physical interface, with different IP subnets for each. The PIX 506E running 6.3(3) or later [such as your 6.3(5)] *will* forward between different IP subnets on the same physical interface, if those subnets are on different "logical interfaces". Which has its own drawbacks: the two logical interfaces will have to be at different security levels than each other and you will need to define nat/global/access-group and so on.

Reply to
Walter Roberson

Cabling-Design.com Forums website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.