internal routing problem with pix

[andy.woo]

Hi all,

I have private point 2 point network, simply HQ and remote site scenario. I have this problem of remote site workstations not able to access servers (eg. not able to ping) located at HQ which the servers default gw are pointing to the pix.

However, the remote site workstations are able to access the Internet via the point 2 point routers and pix; able to ping to the outside network (Internet).

There is already a route inside statement on the pix pointing bk to the HQ point 2 point router for remote network lan segment.

I couldn't figure what else is missing. I guess this shld be a common problem that has solution as I face another similar problem with another customer.

Internet router<-->Pix<--->HQ router<--->private network<--->Remote router<---->remote lan

any pointers for the remote lan to able to ping to HQ lan and access the servers???

[mostiguy]

poust your configs or a diagram of which network segment is where. it is not clear how things are laid out.

client who have the pix as their DG will not be able to send it packets, and have the pix send those back out the same interface to another router on the same subnet as the client

[andy.woo]

oh ok..the HQ and remote lan ere assigned with two different subnets; HQ-->192.168.1.X Remote-->192.168.2.X

the problem again: HQ lan workstations & servers with DG to pix can't ping to remote lan segment. However, remote lan segment can no problem accessing Internet via the point 2 point network and finally via the pix but can't ping or access any HQ lan segment. I thought of changing the HQ lan segment DG to point to the router instead but not really feasible due to huge no. of workstations involved.

[patrick.cannon]

the pix has a default route pointing to the internet but no route for the remote lan?

[andy.woo]

yes, and also a route inside statement "route inside 192.168.2.0 255.255.255.0 " in the pix. without the "route inside" statement, the remote site lan workstations will not be able to access Internet via HQ at all.

[scoclayton]

The symptoms you describe are by design and expected. The PIX will not redirect packets back out the same interface where they were received. In your case, the internal servers are trying to get back to the remote LAN. The servers DG is the inside of the PIX. Since the remote LAN is a different subnet from the servers, the internal servers send their packets to the DG (the inside of the PIX). In order to get from the PIX to the remote LAN, the PIX needs to send the packets back out to the router that connects to your P2P connection. This is the problem...the PIX does not do this.

The best option would be to make the DG for your internal servers be the router that connects your P2P connection. This router would have a specific route across the P2P connection and a default route pointing everything else to the internal interface on the PIX.

Make sense?

Scott

[patrick.cannon]

When you run a traceroute from the remote lan workstations to one of the servers which interface does it break on? The HQ_PN router interface, yes?

When you run a traceroute from the servers to the remote workstations which interface does it break on? The HQ_PIX router interface, yes?

If the above are true, then use a route add statement on a server to point at the remote router_PN interface and test it again. Tell us where the packets appear to be getting dropped.

[andy.woo]

from remote lan-->last hop is at HQ_PN router

from HQ lan-->dropped at first hop which is supposedly the pix

i did advise to use the route add statement but however the server farm has a mixture of mainframe, novell, windows...though most of them work but customer did not like the idea of having the routes on the server.

So I thought does it happen to all firewalls which I dont' remember any such incidents or is it exclusively for pix coz I had a similar environment for another customer the next day and same thing happen..

[patrick.cannon]

1. on a server set up a continuous ping to one of the workstations.

2. on the pix do a debug for the source server ip address and the destination workstation ip address.

3. see what happens. (translation does not exist error?)

Are the HQ router and Pix in the same subnet?

Does the HQ router's default route point to the pix?

[andy.woo]

Yup, the HQ router and Pix are in the same subnet and HQ router's default route points to the pix.

I recalled the debug statement captured to be like "deny icmp src dest ....[no xlate]"

I have already had a similar acl applied at the outside interface which explains why i am able to ping to the outside network (internet) from remote site lan segment.

I have even created an acl on the inside interface "access-list xxx permit icmp any any" which is actually redundant and the acl's hit count did increase during the debug.

from the debug statement, it seems like the packet has problem getting back from hq to remote....which I can figured why

[patrick.cannon]

you "could" turn on terminal monitor briefly and do the ping. It would tell you what is causing the drop. Just be ready with the "term no mon" command...

That would tend to clear your config. If you don't get anything then it is definitely a routing problem.

[andy.woo]

I give up...I will advise the customer to use the add route statement on the servers instead.