Access to remote network across a VPN

Jun 21, 2006 5 Replies

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


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

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

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)

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

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

Join the Discussion

Have something to add? Share your thoughts — no account required.

Didn't find your answer?

Ask the community — no account required