Member Avatar for shanemort

ok guys heres the story...

We have at present 1 main office and 2 sub offices

all 3 have cisco pix's connected together via vpn.

also have guys that can connect from home and auteticate at the main office pix

Dublin (main office)subnet :
Belfast Subnet :
Ashbourne subnet :
Home users static pool :

At present dublin can ping out to all offices and home users that are connected.
But belfast cannot ping ashbourne,
Home user cannot ping belfast or ashbourne and so on.

What statements can i add to route through the dublin pix for a home user to be able to access a shared folder in ashbourne.

Or can it be done??

Please help

  • 2 Contributors
  • 3 Replies
  • 93 Views
  • 3 Days Discussion Span
  • Latest Post Latest Post by w1r3sp33d

Dani AI

Generated

Quick summary for : this topology is doable, but the hub (Dublin) must explicitly carry and advertise the remote-authenticated users' address space across the site-to-site tunnels and each spoke must route those addresses back to the hub. The symptom you described — hub can reach spokes, spokes cannot reach each other or the remote users — almost always means the VPNs only cover the spoke subnets and the remote client pool is missing from the encryption/routing domain. is correct to flag PIX limitations; verify feature support for your PIX code while you work.

Checklist to resolve the problem

  • Make the remote-access address range part of the IPsec "interesting traffic" on the hub and on every spoke so the tunnels will carry client-to-spoke traffic.
  • Ensure each spoke has a route for the remote-access range that points into the tunnel/hub (or that the tunnel covers that range), so replies flow back the same way.
  • Prevent address translation for traffic between internal subnets and the remote pool (address translation will break the IPsec match).
  • Confirm firewall/ACLs on the spokes and the file server allow the file-sharing ports you need.
  • If code or feature limits block this, consider moving the service to the hub or upgrading the PIX/ASA software.

Quick troubleshooting commands to run on the PIXes

show crypto isakmp sa
show crypto ipsec sa
show route
show xlate
show access-list

Notes and cautions: back up configurations before changes and test incrementally. If issues persist after the above checks, capture packet traces on the spoke to confirm where replies are being routed or dropped, and review your PIX software release notes for any VPN-hairpin or client-over-site-to-site limitations.

Recommended Answers

All 3 Replies

Member Avatar for shanemort

Bump :)

Anyone??

Member Avatar for w1r3sp33d

Originally the PIX was certainly not designed that way. There have been, and soon will be some really big advances in routing on the PIX platform but I cannot comment on it's exact status on current code.

If at all humanly possible I would be looking at moving the data out of the shared folder at the remote site and onto a server at the central site. Sorry I can't be more help on this one.

Member Avatar for w1r3sp33d

Put each of the subnets under the NAT 0 and try again.

Be a part of the DaniWeb community

We're a friendly, industry-focused community of developers, IT pros, digital marketers, and technology enthusiasts meeting, networking, learning, and sharing knowledge.