Routing between sites that use site-to-site VPN

[GRANT GATHAGAN]

I have two 515's running 7.2(1) that have a site-to-site VPN set up somewhat as follows:

main site subnets---main site router-------PIX1____Public IP's____PIX2------remote site

The main site router: CAT6506 with SUP1A engine

Subnets listed in SUP engine:

VLAN SUB1

IP address 180.x.1.x.255.254.0

VLAN SUB2

IP address 180.x.2.x.255.254.0

VLAN SUB3

IP address 180.x.3.x.255.254.0

VLAN SUB4

IP address 180.x.4.x.255.255.240

PIX1 is on subnet SUB4(180.20.4.2)

Remote site subnet: 192.168.1.0/24

The SUP engine's default route is directed to another router that reaches the internet through a different public IP subnet.

Any host on SUB4 can reach any host on the remote site as long as the SUB4 host's default gateway is the inside int of PIX1 (180.20.4.2).

Any SUB4 host that uses 180.20.4.1(router address) as the default gateway cannot communicate with any of the remote hosts, but can communicate with any host in any subnet of the main site.

Any remote hosts can communicate with any host on SUB4, regardless of the SUB4 host's gateway address.

Any remote hosts can communicate with the main site router on SUB4, but cannot reach any of the other subnet interfaces configured on the router.

I added a static route on the SUP engine:

ip router 192.168.1.0 255.255.255.0 180.20.4.2

That didn't help.

The SUP engine uses EIGRP to learn of the other main site subnets reached via routers, so I added the remote subnet to that:

router eigrp 10

redistribute static

network 180.20.0.0

network 192.168.1.0

no auto-summary

no eigrp log-neighbor-changes

No luck there, either.

I can't help but think that I'm missing something very basic.

Any help is truly appreciated

[network.king]

Hi ,

Can u pls remove the network 192.168.1.0 and the static route 192.168.1.0 and see wheter you are receiving the subnet via Eigrp if not add a default route pointing to the Pix ip

pls do the same and let us know the results

regards

vanesh k

[GRANT GATHAGAN]

vanesh k,

Thanks for the response.

The network and static route statements were not in the config when I started this project, and I was not able to get it to work, so I put them in to see if it would help.

It did not, obviously :)

I've taken them back out.

As to adding a second default route:

Will that cause any problems with other network traffic ?

I've never had multiple default routes, so this is an unfamiliar area.

I'm assuming that the 192.168.1.0 network would be considered a stub network.

What impact will the 2nd default route have on traffic through the PIX's.

The remote network uses that same PIX (PIX2) for their Internet access.

Thanks again,

g.gathagan

[network.king]

Hi,

I think It would be helpful , if you could send the Switch config and also " sh ip route "from switch and also let us know abt your routing protocol ie Eigrp is running between.. to proceed further .

And I also see a clashing ips between sub2 and sub3

regards

vanesh k

regards

vanesh k

[jgervia_2]

OK -

I'm going to quote some of your note -

"Any host on SUB4 can reach any host on the remote site as long as the SUB4 host's default gateway is the inside int of PIX1 (180.20.4.2)"

Yes. The remote network is only reachable via the VPN.

"Any SUB4 host that uses 180.20.4.1(router address) as the default gateway cannot communicate with any of the remote hosts, but can communicate with any host in any subnet of the main site."

If you added the route you had below (pointing the remote site to the pix), this should work - even though it would be an ICMP redirect to your hosts because your main site router is sending the packet out the same interface it came in on. I'd check routing.

"Any remote hosts can communicate with any host on SUB4, regardless of the SUB4 host's gateway address."

This is explainable if you are natting the remote hosts source IP addresses - if you change the gateway it wouldn't matter because it would look like it's coming from the pix.

"Any remote hosts can communicate with the main site router on SUB4, but cannot reach any of the other subnet interfaces configured on the router."

This sounds like a cryptomap problem, given you have the route below.

"I added a static route on the SUP engine:

ip router 192.168.1.0 255.255.255.0 180.20.4.2"

That should helped a few things.

I would do a couple of things:

1)Verify the subnet masking on sub2/sub3 - you're overlapping there and may have issues - 180.20.2.0/255.255.254.0 and 180.20.3.0/255.255.254.0 are the same 2 class Cs in both places.

2) Verify that your crypto map you're using for interesting traffic on both sides has all the networks in it (*all main site subnet traffic, not just sub 4)

3) You *may* want to consider just trunking to the pix and having it have interfaces on all those vlans and route the remote network to them. Conversely, you may want to take the pix off SUB4 and put it in a small transit network (you could use private addresses, no-one would ever see them).

Really, try to give us the config of the mainsite router and the pixes and we should be able to help more. It definitely sounds like a config issue.

--Jason

Please rate this message if it helped solve some or all of your issue.

[GRANT GATHAGAN]

Vanesh and Jason,

Thanks for the replies.

I apologize for sending you off on a wild goose chase on the subnetting.

Since those are not the actual IP addresses I'm using, when I sanitized them I forgot to number them properly.

In real life there's no overlap, so I should have labeled them as follows:

VLAN SUB1

IP address 180.x.1.x.255.254.0

VLAN SUB2

IP address 180.x.3.x.255.254.0

VLAN SUB3

IP address 180.x.5.x.255.254.0

VLAN SUB4

IP address 180.x.7.x.255.255.240

Accordingly, the main site's PIX inside IP would be 180.x.7.2

Jason, to answer some of your questions:

When I first tried to set this up, I tried the minimalist approach; I used ASDM to create the PIX-to-PIX VPN.

Originally I had the inside interface of PIX1 on my main subnet (SUBNET1) where the vast majority of users were located.

I had the same problem I'm having now.

Since I knew that the PIX's can't route, I decided to create SUB4 as a very small subnet strictly for routing purposes.

No better luck.

In both scenarios, I had tried adding all the main site's subnets to both PIX's

The main site PIX had:

inside route SUB1 255.255.254.0 180.20.7.1

inside route SUB2 255.255.254.0 180.20.7.1

inside route SUB3 255.255.254.0 180.20.7.1

inside route 192.168.1.0 255.255.255.0 180.20.7.2

The remote PIX had:

inside route SUB1 255.255.254.0 192.168.1.1

inside route SUB2 255.255.254.0 192.168.1.1

inside route SUB3 255.255.254.0 192.168.1.1

No luck there.

That's when I started adding static routes to my router and making changes to it's EIGRP settings.

At any rate, as soon as I sanitize the configurations for the PIX's and the router I'll upload them.

Regards.

G

[network.king]

Hi,

Thanx for your detailed response.Now I need to clear some basic question

1.Wheter Ip routing is enabled in the cat65 switch acting as a router -- check by giving a "sh ip route " to see wheter your connected and default route is in the routing table.

2.I think already you have a default route in the cat65 pointing to the Pix

3.If the situation is Ipsec between PIX to PIX , what is eigrp doing in the router --whether providing any routes in the remote site to the cat65 switch

4.If you have default route in the cat65 switch , then you need not add any particular static routes

5.How is the pix routing the end to end lan ips -- is it via default route or some specific route : because I see your remote pix having routes for the main site ip and what is 192.168.1.1 ??

pls clarify to us to check further.

regards

vanesh k

[GRANT GATHAGAN]

vanesh k,

Thanks again for the response.

I'm uploading the config files for the two PIX's and the SUP engine on the 6506. I'm also uploading the results of "sh ip route" on the SUP engine.

For the sake of simplicity, I had not described the entire network, but that has ended up causing more confusion.

I'll upload a JPG that shows the entire data network.

In addition to the setup we're dealing with, I have three other remote locations.

Those three location connect to us via T1 lines.

One of those three is also the connection point for our main Internet access

As I mentioned in my initial post, the main network's route out to the Internet is through another public IP subnet, so the main router's default route points in a completely different direction.

I did not set up the original system, but I assume that EIGRP is used for discovering some of these remote locations.

This is also ignoring the subnets I use for our VoIP phone system, which services all of the locations. You'll see those listed in the 6506's SUP config, as well as the "sh ip route" results.

Note: I got tired of keeping track of real IP addresses versus sanitized ones, so I changed the first two octets and left all the numbers as they really are.

[GRANT GATHAGAN]

Vanesh,

Here's the JPG of the network layout.

[network.king · Accepted solution]

Hi

Pls find the changes that need to be done and checked.

Remote pix :

1.You require only a default route and you cannot route your subnets via inside as they are present outside ,so remove those statements

2.I see a access-group configured to be applied in the outside interface for traffic coming from outside , make sure all the required subnets are allowed .

3.In the access-list for matching traffic in cryptomap , I see only one subnet included , pls have all the traffic included that need to be encrypted ( like sub1 , sub2..)

Main pix :

1.In the access-list for matching traffic in cryptomap , I see only one subnet included , pls have all the traffic included that need to be encrypted ( like sub1 , sub2..)

2.Is there a access-list "access-group outside_access_in" present in the pix matching the traffic --- Check it pls

3.Under nat (inside) 0 access-list inside_nat0_outbound , include all your inside subnets that need access to remote subnet

L3 switch :

1.I see a default route pointing to your 3640 router , so pls add a static route for your remote subnet pointing to Pix

ip route 192.168.1.0 255.255.255.0 x.x.22.2

2.Pls check in your L3 switch , wheter the appropriate subnets sub1 , sub2 are learned properly via Eigrp from the respective vlans conifugred

eg .sub2 and sub3 to be learned with next-hop 8.2 , sub 5 via 30.3

Pls try understanding the topology and make the config changes and let us know the results

regards

vanesh k

[GRANT GATHAGAN]

Ahhhhh...

vanesh k, I think I understand now....

I've been operating under the assumption that the single cryptomap access-list is sufficient since all of the traffic to the remote site is being routed through subnet that the PIX resides on.

But...the PIX's don't care *how* it got there, they care whether or not a particular subnet is on the "approved" list.

So, I need to establish an IPSec tunnel and well as a NAT-exempt entry for each subnet that I want to communicate with from the remote site and vice-versa, correct ?.

Therefore on the main PIX, instead of just:

access-list outside_20_cryptomap extended permit ip SUB4 255.255.255.240 REMOTE 255.255.255.0

access-list inside_nat0_outbound extended permit ip SUB4 255.255.255.240 REMOTE 255.255.255.0

I need to have:

access-list inside_nat0_outbound extended permit ip SUB1 255.255.254.0 REMOTE 255.255.255.0

access-list inside_nat0_outbound extended permit ip SUB2 255.255.254.0 REMOTE 255.255.255.0

access-list inside_nat0_outbound extended permit ip SUB3 255.255.254.0 REMOTE 255.255.255.0

access-list inside_nat0_outbound extended permit ip SUB4 255.255.255.240 REMOTE 255.255.255.0

access-list inside_nat0_outbound extended permit ip SUB5 255.255.254.0 REMOTE 255.255.255.0

access-list outside_20_cryptomap extended permit ip SUB1 255.255.254.0 REMOTE 255.255.255.0

access-list outside_20_cryptomap extended permit ip SUB2 255.255.254.0 REMOTE 255.255.255.0

access-list outside_20_cryptomap extended permit ip SUB3 255.255.254.0 REMOTE 255.255.255.0

access-list outside_20_cryptomap extended permit ip SUB4 255.255.255.240 REMOTE 255.255.255.0

access-list outside_20_cryptomap extended permit ip SUB5 255.255.254.0 REMOTE 255.255.255.0

and on the REMOTE PIX, I need:

access-list outside_20_cryptomap extended permit ip REMOTE 255.255.255.0 SUB1 255.255.254.0

access-list outside_20_cryptomap extended permit ip REMOTE 255.255.255.0 SUB2 255.255.255.0

access-list outside_20_cryptomap extended permit ip REMOTE 255.255.255.0 SUB3 255.255.254.0

access-list outside_20_cryptomap extended permit ip REMOTE 255.255.255.0 SUB4 255.255.254.240

access-list outside_20_cryptomap extended permit ip REMOTE 255.255.255.0 SUB5 255.255.254.0

access-list inside_nat0_outbound extended permit ip REMOTE 255.255.255.0 SUB1 255.255.255.0

access-list inside_nat0_outbound extended permit ip REMOTE 255.255.255.0 SUB2 255.255.254.0

access-list inside_nat0_outbound extended permit ip REMOTE 255.255.255.0 SUB3 255.255.254.0

access-list inside_nat0_outbound extended permit ip REMOTE 255.255.255.0 SUB4 255.255.254.240

access-list inside_nat0_outbound extended permit ip REMOTE 255.255.255.0 SUB5 255.255.254.0

As to the L3 switch router, I'll add the static route back in. As you recall, that was in the original config and I had taken it out at your request.

I'll report back as to the results.

[GRANT GATHAGAN]

Well, that didn't fix it.

Here's the config changes:

On remote PIX:

1. Only default route exists

2.The statement is: "access-group outside_access_in in interface outside"

3: crypto-map and acccess-list statements

access-list outside_20_cryptomap extended permit ip REMOTE 255.255.255.0 SUB3 255.255.254.0

access-list outside_20_cryptomap extended permit ip REMOTE 255.255.255.0 SUB4 255.255.255.240

access-list outside_20_cryptomap extended permit ip REMOTE 255.255.255.0 SUB5 255.255.254.0

access-list outside_20_cryptomap extended permit ip REMOTE 255.255.255.0 SUB1 255.255.254.0

access-list outside_20_cryptomap extended permit ip REMOTE 255.255.255.0 SUB2 255.255.254.0

access-list inside_nat0_outbound extended permit ip REMOTE 255.255.255.0 SUB4 255.255.255.240

access-list inside_nat0_outbound extended permit ip REMOTE 255.255.255.0 SUB3 255.255.254.0

access-list inside_nat0_outbound extended permit ip REMOTE 255.255.255.0 SUB5 255.255.254.0

access-list inside_nat0_outbound extended permit ip REMOTE 255.255.255.0 SUB 255.255.254.0

access-list inside_nat0_outbound extended permit ip REMOTE 255.255.255.0 SUB2 255.255.254.0

On the main PIX:

1. Matching traffic crypto-map statements:

access-list outside_20_cryptomap extended permit ip SUB3 255.255.254.0 REMOTE 255.255.255.0

access-list outside_20_cryptomap extended permit ip SUB4 255.255.255.240 REMOTE 255.255.255.0

access-list outside_20_cryptomap extended permit ip SUB5 255.255.254.0 REMOTE 255.255.255.0

access-list outside_20_cryptomap extended permit ip SUB1 255.255.254.0 REMOTE 255.255.255.0

access-list outside_20_cryptomap extended permit ip SUB2 255.255.254.0 REMOTE 255.255.255.0

2.The statement is: "access-group outside_access_in in interface outside"

3.Under nat (inside) 0 access-list:

access-list inside_nat0_outbound extended permit ip SUB3 255.255.254.0 REMOTE 255.255.255.0

access-list inside_nat0_outbound extended permit ip SUB4 255.255.255.240 REMOTE 255.255.255.0

access-list inside_nat0_outbound extended permit ip SUB5 255.255.254.0 REMOTE 255.255.255.0

access-list inside_nat0_outbound extended permit ip SUB1 255.255.254.0 REMOTE 255.255.255.0

access-list inside_nat0_outbound extended permit ip SUB2 255.255.254.0 REMOTE 255.255.255.0

L3 switch

1. Added "ip route 192.168.1.0 255.255.255.0 180.20.22.2" back in.

2. Here are the routes learned via EIGRP and their descriptions:

D 180.20.32.0/23 [90/2178816] via 180.20.8.2, 3d13h, Vlan8: T1 link from MAIN 3640 to SUB2

D 180.20.26.0/23 [90/2181376] via 180.20.8.2, 3d13h, Vlan8: SUB2

D 180.20.28.0/23 [90/2181376] via 180.20.8.2, 3d13h, Vlan8: VoIP subnet at SUB2

D 180.20.10.0/23 [90/2178816] via 180.20.8.2, 3w1d, Vlan8: T1 link from MAIN 3640 to SUB3:

D 180.20.14.0/23 [90/2181376] via 180.20.8.2, 3d17h, Vlan8: SUB3

D 180.20.16.0/23 [90/2181376] via 180.20.8.2, 3w1d, Vlan8: VoIP subnet at SUB3

D 180.20.34.0/23 [90/2178816] via 180.20.30.3, 3w1d, Vlan1: T1 link from MAIN 1760 to SUB5

D 180.20.38.0/23 [90/2181376] via 180.20.30.3, 3w1d, Vlan1: VoIP subnet at SUB5

Here are the rest of the ip routes listed on the 6506

C 180.20.22.0/28 is directly connected, Vlan22: SUB4

C 180.20.8.0/23 is directly connected, Vlan8: subnet between MAIN 6506 and MAIN 3640

C 180.20.30.0/23 is directly connected, Vlan1: SUB1

C 180.20.24.0/23 is directly connected, Vlan24: VoIP subnet at REMOTE

S 180.20.36.0/23 [1/0] via 180.20.30.3: SUB5

C 180.20.2.0/23 is directly connected, Vlan4: MAIN CCM subnet

C 180.20.6.0/23 is directly connected, Vlan100: MAIN VoIP subnet

C 127.0.0.0/8 is directly connected, EOBC0/0

S 192.168.1.0/24 [1/0] via 180.20.22.2

S* 0.0.0.0/0 [1/0] via 180.20.8.2

[network.king]

Hi,

Just wanted to clarify , " access-group outside_access_in " is present in your PIX , but is that you have a access-list for outside_access_in in both the firewalls.

Let us know wheter Ipsec tunnel is up between both the firewalls and make a trace from one of your pc for the remote ip

regards

vanesh k

[GRANT GATHAGAN]

vanesh k,

The " access-group outside_access_in " *is* present on both PIX's but the only traffic that I'm currently allowing from outside of the PIX is through the IPSec tunnel, so there are no access-lists.

As to the IPSec tunnel, that has always worked.

I am unclear as to what you are asking for when you ask for a trace from one of my PC's to the remote IP.

Since I cannot communicate to the remote site from any subnet other than from a PC on the SUB4 subnet, I don't really get a trace. I just get:

C:\>tracert 192.168.1.26

Tracing route to 192.168.1.26 over a maximum of 30 hops

1 7 ms 7 ms 4 ms 192.168.1.26

Trace complete.

Please clarify what kind of trace you are asking for.

g.gathagan

[network.king]

Hi,

Thanx for your update . I was just asking for a trace from a pc in any segment other than sub4 and default as router ip rather than the pix.

regards

vanesh k