1. Home
  2. Cisco Systems
  3. Access to remote network across a VPN

Access to remote network across a VPN

I have the following setup

10.3.0.0 10.1.0.0 Internet 10.2.0.0

I can talk from

10.1.0.0 to 10.3.0.0 10.3.0.0 to 10.1.0.0 10.1.0.0 to 10.2.0.0 10.2.0.0 to 10.1.0.0

I'd like to be able to talk from

10.2.0.0 to 10.3.0.0 10.3.0.0 to 10.2.0.0

Seems that my Packet leaving 10.3.0.0 Hit the PIX on 10.1.0.0 but it does not know to send it over the VPN Link

How does routing work over a VPN?

Trace route from 10.2.0.0 to 10.3.0.0 dies at PIX B

Traceroute from 10.3.0.0 to 10.2.0.0 Dies at PIX A

Both PIXs are set up similar to this:

access-list inside_nat extended permit ip 10.2.0.0 255.255.0.0 10.1.0.0

255.255.0.0 access-list inside_nat extended permit ip 10.2.0.0 255.255.0.0 10.3.0.0 255.255.0.0

access-list outside-SF_nat0_outbound extended permit ip 10.2.0.0 255.255.0.0

10.1.0.0 255.255.0.0 access-list outside-SF_nat0_outbound extended permit ip 10.1.0.0 255.255.0.0 10.2.0.0 255.255.0.0 access-list outside-SF_nat0_outbound extended permit ip 10.1.0.0 255.255.0.0 10.3.0.0 255.255.0.0 access-list outside-SF_nat0_outbound extended permit ip 10.3.0.0 255.255.0.0 10.1.0.0 255.255.0.0 access-list outside-SF_nat0_outbound extended permit ip 10.2.0.0 255.255.0.0 10.3.0.0 255.255.0.0 access-list outside-SF_nat0_outbound extended permit ip 10.3.0.0 255.255.0.0 10.2.0.0 255.255.0.0

access-list outside-SF_nat0_inbound extended permit ip 10.2.0.0 255.255.0.0

10.1.0.0 255.255.0.0 access-list outside-SF_nat0_inbound extended permit ip 10.1.0.0 255.255.0.0 10.2.0.0 255.255.0.0 access-list outside-SF_nat0_inbound extended permit ip 10.1.0.0 255.255.0.0 10.3.0.0 255.255.0.0 access-list outside-SF_nat0_inbound extended permit ip 10.3.0.0 255.255.0.0 10.1.0.0 255.255.0.0 access-list outside-SF_nat0_inbound extended permit ip 10.2.0.0 255.255.0.0 10.3.0.0 255.255.0.0 access-list outside-SF_nat0_inbound extended permit ip 10.3.0.0 255.255.0.0 10.2.0.0 255.255.0.0

access-list outside-SF_cryptomap_20 extended permit ip 10.2.0.0 255.255.0.0

10.3.0.0 255.255.0.0 access-list outside-SF_cryptomap_20 extended permit ip 10.3.0.0 255.255.0.0 10.2.0.0 255.255.0.0 access-list outside-SF_cryptomap_20 extended permit ip 10.1.0.0 255.255.0.0 10.2.0.0 255.255.0.0 access-list outside-SF_cryptomap_20 extended permit ip 10.2.0.0 255.255.0.0 10.1.0.0 255.255.0.0 access-list outside-SF_cryptomap_20 extended permit ip 10.1.0.0 255.255.0.0 10.3.0.0 255.255.0.0 access-list outside-SF_cryptomap_20 extended permit ip 10.3.0.0 255.255.0.0 10.1.0.0 255.255.0.0

access-list charlie_tunnel extended permit ip 10.2.0.0 255.255.0.0 10.1.0.0

255.255.0.0 access-list charlie_tunnel extended permit ip 10.1.0.0 255.255.0.0 10.2.0.0 255.255.0.0 access-list charlie_tunnel extended permit ip 10.1.0.0 255.255.0.0 10.3.0.0 255.255.0.0 access-list charlie_tunnel extended permit ip 10.3.0.0 255.255.0.0 10.1.0.0 255.255.0.0 access-list charlie_tunnel extended permit ip 10.2.0.0 255.255.0.0 10.3.0.0 255.255.0.0 access-list charlie_tunnel extended permit ip 10.3.0.0 255.255.0.0 10.2.0.0 255.255.0.0

nat (outside-SF) 0 access-list outside-SF_nat0_outbound nat (outside-SF) 0 access-list outside-SF_nat0_inbound outside nat (inside-SF) 0 access-list inside_nat nat (inside-SF) 1 10.2.0.0 255.255.0.0 nat (dmz-sf) 0 access-list dmz-sf_nat0_outbound access-group acl_outside in interface outside-SF route outside-SF 0.0.0.0 0.0.0.0 1

group-policy charlie internal group-policy charlie attributes split-tunnel-policy tunnelspecified split-tunnel-network-list value charlie_tunnel

crypto map outside-SF_map 20 match address outside-SF_cryptomap_20

Reply to
Scott Townsend
Loading thread data ...

On PIX A you will need a static route for the 10.3.0.0 network pointing to the T1 router

route inside 10.3.0.0 255.255.255.0 10.1.0.x

Reply to
mcaissie

I do have that in there. I think I messed something else up.

I can no longer initiate a communication from 10.1.0.0 to 10.2.0.0

I can initiate connections from 10.2.0.0 to 10.1.0.0

So I can terminal serve, access server shares, etc to machines in 10.1.0.0 from 10.2.0.0 but not the other way around...

Now I'm getting the Following in the log of PIX A

%PIX-3-305006: portmap translation creation failed for icmp src inside-HBG:10.3.0.5 dst inside-HBG:10.2.0.5 (type 8, code 0)

I'm at the location of PIX B, I cant leave till I can reach PIX B from Site A!!! AARRGG!!!

Scott On PIX A you will need a static route for the 10.3.0.0 network pointing to

Reply to
Scott Townsend

If the PIX tried to create a translation for 10.3 to 10.2 , it means that you have a missing line in your nat 0 statement for the inside ( your nat_inside acl)

Reply to
mcaissie

So should all my Access list have the Subnets to/from each other listed?

i.e.

access-list inside_nat extended permit ip 10.1.0.0 255.255.0.0 10.2.0.0

255.255.0.0 access-list inside_nat extended permit ip 10.1.0.0 255.255.0.0 10.3.0.0 255.255.0.0 access-list inside_nat extended permit ip 10.2.0.0 255.255.0.0 10.1.0.0 255.255.0.0 access-list inside_nat extended permit ip 10.2.0.0 255.255.0.0 10.3.0.0 255.255.0.0 access-list inside_nat extended permit ip 10.3.0.0 255.255.0.0 10.1.0.0 255.255.0.0 access-list inside_nat extended permit ip 10.3.0.0 255.255.0.0 10.2.0.0 255.255.0.0

Or do they just need to be one direction? access-list inside_nat extended permit ip 10.2.0.0 255.255.0.0 10.1.0.0

255.255.0.0 access-list inside_nat extended permit ip 10.2.0.0 255.255.0.0 10.3.0.0 255.255.0.0

then what about the Outside interface inbound/outbound NAT ACLs? List all in each direction? nat (outside-SF) 0 access-list outside-SF_nat0_outbound nat (outside-SF) 0 access-list outside-SF_nat0_inbound outside

Then the Same for the CryMap and Tunnel ACLs?

I was thinking of doing the Following for all of the lists: object-group network NETWORK-VPN-ALL network-object 10.1.0.0 255.255.0.0 network-object 10.2.0.0 255.255.0.0 network-object 10.3.0.0 255.255.0.0 network-object 10.6.0.0 255.255.0.0

object-group protocol VPN-PROTOCOLS protocol-object ip protocol-object tcp protocol-object udp protocol-object icmp

access-list outside-HBG_nat0_outbound extended permit object-group VPN-PROTOCOLS object-group NETWORK-VPN-ALL object-group NETWORK-VPN-ALL

Reply to
Scott Townsend

I did add in the Groups to the ACLs and then also found that I had a Route on PIX A that was for 10.2.0.0 pointing to 10.2.0.1 PIX B I took that out and things are much better...

Thank you for your assistance!

Scott> %PIX-3-305006: portmap translation creation failed for icmp src

Reply to
Scott Townsend

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.