Solved: URGENT Routing problem...

jquintard · ‎02-06-2012

Hello,

A VPN is used to link two sites. Each site have a router. Each router have a DSL link.

Like this :

DSL - Router1 ---- VPN --- Router2 - DSL

Users from the second site use the DHCP and DNS server on the first site.

Since I have added a second link on my first site with a PBR, I can only ping gateway from the other site but it's impossible to reach any adress behind each router. Below my conf :

Router 1 (site 1)

interface GigabitEthernet0/0
no ip address

     interface GigabitEthernet0/0.20
       description DSL1
       encapsulation dot1Q 20
       ip address 109.3.140.34 255.255.255.240
       ip nat outside

     interface GigabitEthernet0/0.30
       description VPN
       encapsulation dot1Q 30
       ip address 10.10.20.1 255.255.255.0

     interface GigabitEthernet0/0.40
       description DSL2
       encapsulation dot1Q 40
       ip address 10.10.21.1 255.255.255.0
       ip nat outside

interface GigabitEthernet0/1
no ip address
ip nat inside

      interface GigabitEthernet0/1.101
       description LAN
       encapsulation dot1Q 101
       ip address 10.10.10.1 255.255.255.0
       ip nat inside
       ip policy route-map PBR

      interface GigabitEthernet0/1.110
       description VoIP
       encapsulation dot1Q 110
       ip address 10.30.10.1 255.255.255.0
       ip helper-address 10.10.10.21
       ip nat inside

router rip
version 2
network 10.0.0.0
no auto-summary

ip nat inside source route-map DSL1 interface GigabitEthernet0/0.20 overload

ip nat inside source route-map DSL2 interface GigabitEthernet0/0.40 overload

ip route 0.0.0.0 0.0.0.0 10.10.21.10 10
ip route 0.0.0.0 0.0.0.0 109.3.140.33 20

ip route 10.10.11.0 255.255.255.0 10.10.20.10
ip route 10.10.12.0 255.255.255.0 10.10.20.10
ip route 10.10.30.0 255.255.255.0 10.10.20.10
ip route 10.31.10.0 255.255.255.0 10.10.20.10

access-list 1 permit 10.10.10.0 0.0.0.255
access-list 1 permit 10.30.10.0 0.0.0.255

access-list 120 remark Capture 10.10.10.1-59/24
access-list 120 permit ip 10.10.10.0 0.0.0.31 any
access-list 120 permit ip 10.10.10.32 0.0.0.15 any
access-list 120 permit ip 10.10.10.48 0.0.0.7 any
access-list 120 permit ip 10.10.10.56 0.0.0.3 any
access-list 120 permit tcp any any eq 1433
access-list 120 permit tcp any any eq 3389
access-list 120 permit tcp any any eq 22

access-list 130 permit ip 10.10.11.0 0.0.0.255 any
access-list 130 permit ip 10.10.12.0 0.0.0.255 any

access-list 140 permit ip any any

route-map DSL1 permit 20
match ip address 1
match interface GigabitEthernet0/0.20

route-map DSL2 permit 40
match ip address 1
match interface GigabitEthernet0/0.40

route-map PBR permit 20
description ToDSL1
match ip address 120
set ip next-hop 109.3.140.33

route-map PBR permit 30

description TestToVPN
match ip address 130
set interface GigabitEthernet0/0.30

route-map PBR permit 40
description ToDSL2

match ip address 140
set interface GigabitEthernet0/0.40

Router 2 (site 2)

interface GigabitEthernet0/0
no ip address

      interface GigabitEthernet0/0.30
       description VPN
       encapsulation dot1Q 30
       ip address 10.10.30.1 255.255.255.0

      interface GigabitEthernet0/0.40
       description DSL
       encapsulation dot1Q 40
       ip address 10.10.31.1 255.255.255.0
       ip nat outside

interface GigabitEthernet0/1
no ip address
ip nat inside

     interface GigabitEthernet0/1.1
       description Lan Antares
       encapsulation dot1Q 1 native
       ip address 10.10.11.1 255.255.255.0
       ip helper-address 10.10.10.21
       ip nat inside

     interface GigabitEthernet0/1.10
       description VoIP
       encapsulation dot1Q 10
       ip address 10.31.10.1 255.255.255.0
       ip helper-address 10.10.10.21
       ip nat inside

router rip
version 2
network 10.0.0.0
no auto-summary

ip nat inside source list 1 interface GigabitEthernet0/0.40 overload

ip route 0.0.0.0 0.0.0.0 10.10.31.10

ip route 10.10.10.0 255.255.255.0 10.10.30.10
ip route 10.10.20.0 255.255.255.0 10.10.30.10
ip route 10.30.10.0 255.255.255.0 10.10.30.10

access-list 1 permit 10.10.11.0 0.0.0.255
access-list 1 permit 10.10.12.0 0.0.0.255

If I try to tracert 10.10.11.54 (from Router1) that stop to 10.10.30.1

If I try to tracert 10.10.10.21 (from Router2) that stop to 10.10.20.1

I think the problem come from the PRB. If I try to tracert 10.30.10.10 that work.

Where is the problem ?

Jerome

Richard Burts · ‎02-07-2012

Jerome

There seems to be confusion about which access list is filtering what traffic. In the recent post you made an example denying 10.10.11.0 and 10.10.12.0 in access list 120. So I responded with an example using access list 120. But in looking at the original post I see that access list 120 really does not have anything to do with 10.10.11.0 or 10.10.12.0. The filtering for these addresses is in access list 130 so the deny statements need to go into access list 130.

Also be aware that when you just add statements to an access lsit the new statements will go at the bottom of the list. Since access lists are processed a line at a time starting at the top you need to make sure that the new statements with deny will come before the statements with permit.

HTH

Rick

HTH

Rick

View solution in original post

jquintard · ‎02-06-2012

The problem come from the PBR. If I remove the PBR that work but it's not a solution

I dont understand why the sequence 30 of the route-map PBR is never matched :

route-map PBR, permit, sequence 20
Match clauses:
ip address (access-lists): 120
Set clauses:
ip next-hop 109.3.140.33
Policy routing matches: 7728441 packets, 1419074393 bytes

route-map PBR, permit, sequence 30
Match clauses:
ip address (access-lists): 130
Set clauses:
interface GigabitEthernet0/0.30
Policy routing matches: 97 packets, 29582 bytes

route-map PBR, permit, sequence 40
Match clauses:
ip address (access-lists): 140
Set clauses:
interface GigabitEthernet0/0.40
Policy routing matches: 3705214 packets, 925984775 bytes

I dont understand this problem...

jquintard · ‎02-06-2012

I think I have understand but I dont know how to resolve this problem.

In a normal situation without PBR

If I tracert a server connected to dsl1 on router2 from a computer behind router1 :

1. 10.10.11.1 Router2

2. 10.10.30.10 VPN CE Site 2

3. x.x.x.x VPN PE

4. 10.10.20.1 Router1

5. 10.10.10.21 My Server

From my server to 10.10.11.50 (the computer behind router2) :

1. 10.10.10.1 Router1

2. 10.10.20.10 VPN CE Site 1

3. x.x.x.x VPN PE

4. 10.10.30.1 Router2

5. 10.10.11.50 My Computer

With the PBR

There are a problem with the return. My route-map force the next-hop to use DSL1 and NOT the VPN. So how to change the next-hop only if packets are not for a local address ?

Luca Tortiglione · ‎02-06-2012

what about to use extended ACL ?

Richard Burts · ‎02-06-2012

Jerome

Basically the problem is that the access lists used in the route map are too general and permit too much. Access list 120 and 130 specify source addresses but permit any destination. What they need to do is to deny traffic from sources on router 2 and with destination on router 1 and then permit other traffic with source on router 2.

And I am puzzled that one of your posts says that you are surprised that there are no matches in sequence 30 when the output clearly shows that there have been 97 matches.

route-map PBR, permit, sequence 30

Match clauses:

ip address (access-lists): 130

Set clauses:

interface GigabitEthernet0/0.30

Policy routing matches: 97 packets, 29582 bytes

HTH

Rick

HTH

Rick

jquintard · ‎02-06-2012

Richard,

Yep, I have understand, it's missing some deny in my ACLs like this ? :

access-list 120 remark Capture 10.10.10.1-59/24

access-list 120 deny ip any 10.10.11.0 0.0.0.255

access-list 120 deny ip any 10.10.12.0 0.0.0.255

access-list 120 permit ip 10.10.10.0 0.0.0.31 any

access-list 120 permit ip 10.10.10.32 0.0.0.15 any

access-list 120 permit ip 10.10.10.48 0.0.0.7 any

access-list 120 permit ip 10.10.10.56 0.0.0.3 any

access-list 120 permit tcp any any eq 1433

access-list 120 permit tcp any any eq 3389

access-list 120 permit tcp any any eq 22

Richard Burts · ‎02-06-2012

Jerome

I think that you did not quite understand what I was suggesting about the deny statements. What you have done in the recent post is to switch 10.10.11.0 from the source address to the destination address. That will not solve the problem. What you want to do is to deny traffic where the remote subnets are the source and the local subnets are thee destination. So for example one entry might look like this

access-list 120 deny ip 10.10.11.0 0.0.0.255 10.10.10.0 0.0.0.255

So if some PC in the remote 10.10.11.0 subnet is sending to (or is replying to) some PC in the 10.10.10.0 subnet that traffic should be denied so that PBR will not send it off in a different direction. You would need additional statements like this to take care of the various remote subnets and the various local subnets and then you would have the permit statements that permit the remote subnets so that PBR will process them.

HTH

Rick

HTH

Rick

jquintard · ‎02-07-2012

Rick,

I have modify my ACL but that doesn't work...

access-list 120 remark Capture 10.10.10.1-59/24

access-list 120 permit ip 10.10.10.0 0.0.0.31 any

access-list 120 permit ip 10.10.10.32 0.0.0.15 any

access-list 120 permit ip 10.10.10.48 0.0.0.7 any

access-list 120 permit ip 10.10.10.56 0.0.0.3 any

access-list 120 permit tcp any any eq 1433

access-list 120 permit tcp any any eq 3389

access-list 120 permit tcp any any eq 22

access-list 120 deny ip 10.10.11.0 0.0.0.255 10.10.10.0 0.0.0.255

access-list 120 deny ip 10.10.12.0 0.0.0.255 10.10.10.0 0.0.0.255

Richard Burts · ‎02-07-2012

Jerome

There seems to be confusion about which access list is filtering what traffic. In the recent post you made an example denying 10.10.11.0 and 10.10.12.0 in access list 120. So I responded with an example using access list 120. But in looking at the original post I see that access list 120 really does not have anything to do with 10.10.11.0 or 10.10.12.0. The filtering for these addresses is in access list 130 so the deny statements need to go into access list 130.

Also be aware that when you just add statements to an access lsit the new statements will go at the bottom of the list. Since access lists are processed a line at a time starting at the top you need to make sure that the new statements with deny will come before the statements with permit.

HTH

Rick

HTH

Rick

jquintard · ‎02-08-2012

Richard,

I have change my ACL with this settigns :

access-list 1 permit 10.10.10.0 0.0.0.255

access-list 1 permit 10.30.10.0 0.0.0.255

access-list 120 remark Capture 10.10.10.1-59/24

access-list 120 permit ip 10.10.10.0 0.0.0.31 any

access-list 120 permit ip 10.10.10.32 0.0.0.15 any

access-list 120 permit ip 10.10.10.48 0.0.0.7 any

access-list 120 permit ip 10.10.10.56 0.0.0.3 any

access-list 120 permit tcp any any eq 1433

access-list 120 permit tcp any any eq 3389

access-list 120 permit tcp any any eq 22

access-list 130 deny ip 10.10.11.0 0.0.0.255 10.10.10.0 0.0.0.255

access-list 130 deny ip 10.10.12.0 0.0.0.255 10.10.10.0 0.0.0.255

access-list 140 permit ip any any

access-list 140 deny ip 10.10.11.0 0.0.0.255 10.10.10.0 0.0.0.255

access-list 140 deny ip 10.10.12.0 0.0.0.255 10.10.10.0 0.0.0.25

but that allways doesn't work. I don't understand why the sequence 30 have no packet matched...

route-map PBR, permit, sequence 20

Match clauses:

ip address (access-lists): 120

Set clauses:

ip next-hop 109.3.140.33

Policy routing matches: 7759797 packets, 1423998228 bytes

route-map PBR, permit, sequence 30

Match clauses:

ip address (access-lists): 130

Set clauses:

interface GigabitEthernet0/0.30

Policy routing matches: 0 packets, 0 bytes

route-map PBR, permit, sequence 40

Match clauses:

ip address (access-lists): 140

Set clauses:

interface GigabitEthernet0/0.40

Policy routing matches: 3719589 packets, 933999960 bytes

Richard Burts · ‎02-08-2012

Jerome

The reason that sequence 30 does not work is that the access list 130 now has only deny statements. What I was suggesting was to add the deny statements ahead of the existing permit statements. So it should look something like this

access-list 130 deny ip 10.10.11.0 0.0.0.255 10.10.10.0 0.0.0.255

access-list 130 deny ip 10.10.12.0 0.0.0.255 10.10.10.0 0.0.0.255

access-list 130 permit ip 10.10.11.0 0.0.0.255 any

access-list 130 permit ip 10.10.12.0 0.0.0.255 any

Also if you look at access list 140 in the most recent post you will see the issue that I talked about when you add statements to an access list. The access list has added two deny statements but they come after a statement with permit ip any any. So the deny statements will never be matched because all traffic matches the first statement. For the access list to do what you want it to do the deny statements must come before the permit ip any any.

HTH

Rick

HTH

Rick