02-06-2012 02:04 AM - edited 03-04-2019 03:09 PM
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 addressinterface GigabitEthernet0/0.20
description DSL1
encapsulation dot1Q 20
ip address 109.3.140.34 255.255.255.240
ip nat outsideinterface GigabitEthernet0/0.30
description VPN
encapsulation dot1Q 30
ip address 10.10.20.1 255.255.255.0interface GigabitEthernet0/0.40
description DSL2
encapsulation dot1Q 40
ip address 10.10.21.1 255.255.255.0
ip nat outsideinterface GigabitEthernet0/1
no ip address
ip nat insideinterface 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 insiderouter rip
version 2
network 10.0.0.0
no auto-summaryip 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 20ip 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.10access-list 1 permit 10.10.10.0 0.0.0.255
access-list 1 permit 10.30.10.0 0.0.0.255access-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 22access-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 anyaccess-list 140 permit ip any any
route-map DSL1 permit 20
match ip address 1
match interface GigabitEthernet0/0.20route-map DSL2 permit 40
match ip address 1
match interface GigabitEthernet0/0.40route-map PBR permit 20
description ToDSL1
match ip address 120
set ip next-hop 109.3.140.33route-map PBR permit 30
description TestToVPN
match ip address 130
set interface GigabitEthernet0/0.30route-map PBR permit 40
description ToDSL2match 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.0interface GigabitEthernet0/0.40
description DSL
encapsulation dot1Q 40
ip address 10.10.31.1 255.255.255.0
ip nat outsideinterface GigabitEthernet0/1
no ip address
ip nat insideinterface 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 insideinterface 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-summaryip 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
Solved! Go to Solution.
02-07-2012 12:43 PM
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
02-06-2012 02:25 AM
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 bytesroute-map PBR, permit, sequence 30
Match clauses:
ip address (access-lists): 130
Set clauses:
interface GigabitEthernet0/0.30
Policy routing matches: 97 packets, 29582 bytesroute-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...
02-06-2012 02:47 AM
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 ?
02-06-2012 03:11 AM
what about to use extended ACL ?
02-06-2012 04:44 AM
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
02-06-2012 05:20 AM
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
02-06-2012 01:48 PM
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
02-07-2012 09:44 AM
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
02-07-2012 12:43 PM
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
02-08-2012 07:16 AM
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
02-08-2012 09:07 AM
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
Discover and save your favorite ideas. Come back to expert answers, step-by-step guides, recent topics, and more.
New here? Get started with these tips. How to use Community New member guide