cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
2551
Views
0
Helpful
14
Replies

Source routing out of different interfaces

ncox67890
Level 1
Level 1

internal interface Vlan1 on 192.168.1.0/24

external interface ATM0.1 (a PPPoATM interface but you don't really care)

external interface Dialer0 (a pptp vpn tunnel but you don't really care)

I need to route the 192.168.1.0/24 over ATM0.1 as a policy and selectively route specific hosts over Dialer0.

So access lists and route-map, right?

ip access-list extended NOVPN

permit ip 192.168.1.0 0.0.0.255 any            (this matches all 192.168.1.0/24 sourced traffic)

ip access-list extended VPN

permit ip host 192.168.1.86 any                (this matches specific host sourced traffic)

route-map ROUTE-THIS-OVER-THE-VPN

match ip address VPN                                   (a route-map that references the traffic we

                                                                        matched with the ACL as going over the vpn (Dialer0)

route-map DONT-ROUTE-THIS-OVER-THE-VPN

match ip address NOVPN                                         (a route-map that references the traffic we

                                                                                   matched with the ACL as going over ATM0.1)

All done, we need to do nat

ip nat inside source route-map ROUTE-THIS-OVER-THE-VPN interface Dialer0 overload

ip nat inside source route-map DONT-ROUTE-THIS-OVER-THE-VPN interface ATM0.1 overload

What happens after all this is that the NOVPN access list gets evaluated (increase counters)

matches the subnet traffic and sends ALL over ATM0.1  (which is expected)

The VPN access-list that supposed to match the single host doesn't get evaluated (counters 0)

and even hosts specified there go over ATM0.1 as well. (this is not expected, we asked for anything that matches the VPN access-list to go over Dialer0)

Ideas?

I would be happy to explain more anything that's not clear enough. Please focus on the routing, both out-facing interfaces are configured correctly.

If i edit the interface on the nat statement, traffic flows happily either over Dialer0 or ATM0.1 Of course that's not the textbook way to do it, basically i need a way to route x.x.x.x/24 over interface A and x.x.x.2/24 and x.x.x.3/24 over int B, all hosts belonging to the same subnet.

Thanks

1 Accepted Solution

Accepted Solutions

Hello nn cox,

>> As previously mentioned, if you deny traffic on a statement it get's dropped, longest match wins, it matches, it's denied, it's dropped.

This is not true, the real behaviour depends on application: for PBR a deny statement means that traffic matching the deny statement will be normally routed by destination, for NAT means the traffic matching the deny statement will be not translated.

About your issue, a possible approach could be is that of using PBR on internal interface + NAT with route-maps statements as suggested by Gamiel.

But to do a clean configuration we use different route-maps for PBR and for NAT

PBR route-map

access-list 101 permit host 192.168.1.86 any

access-list 102 deny host 192.168.1.86 any

access-list 102 permit ip 192.168.1.0 0.0.0.255 any

route-map PBR permit 10

match ip address 101

set interface Dialer0

route-map PBR permit 20

match ip address 102

set interface ATM0.1

interface Vlan1

ip policy route-map PBR

ip nat inside

this works on the internal interface on inbound traffic

NAT route-maps

route-map NAT1 permit 10

match ip address 101

match interface dialer0

route-map NAT2 permit 20

match ip address 102

match interface ATM0.1

ip nat inside source route-map NAT1 interface dialer0 overload

ip nat inside source route-map NAT2 interface ATM0.1 overload

Hope to help

Giuseppe

View solution in original post

14 Replies 14

gamalielcruz
Level 1
Level 1

Have you tried denying the individual hosts in ip access-list extended NOVPN?

Access lists are evaluated in order, if i deny the specific hosts traffic would just DROP.

First match wins.

Ok. Then maybe you can try adding match interface to each of your route-maps.

ROUTE-THIS-OVER-THE-VPN to Dialer and the other to ATM.

Thanks!

match interface?? I believe you mean set interface, something along the lines of..

route-map ROUTE-THIS-OVER-THE-VPN

match ip address VPN  

set interface Dialer0

route-map DONT-ROUTE-THIS-OVER-THE-VPN

match ip address NOVPN

set interface ATM0.1

Tried, no cigar.

Have you tried doing it the other way around and apply the route map to the source interface?

Ex:

access-list 1 permit ip 192.168.1.86

access-list 2 permit 192.168.1.0 0.0.0.255

LAN interface

ip policy route-map MAP

route-map MAP permit 10

match ip address 1

set interface Dialer0

route-map MAP permit 20

match ip address 2

set interface ATM0.1

Thanks!

Using your example above it's the first time that i see the vpn acl getting matches on the counters, half the way there.

Let me check if we actually exit on the right interface.

No go. The router traffic works but i need the nat staments for the return traffic to the hosts.

Using your suggestion and:

ip nat inside source list 1 interface Dialer0 overload

ip nat inside source list 2 interface ATM0.1 overload

the host side breaks, router has network reachability but the nat'd hosts do not.

I'm almost sure the problem is with the translation statements somewhere. If i try a catch-all situation, dropping the whole subnet in a FOO acl and then:

ip nat inside source list FOO interface Dialer0 overload           (this works alone and goes happily over the vpn

                                                                                                                             for ALL hosts)

or

ip nat inside source list FOO interface ATM0.1 overload          (this works alone and goes happily over atm0

                                                                                                                                for ALL hosts)

So the transport on the interfaces is perfectly fine, the problem is with the translations?

I thought such a simple setup and config would be elementary for the thousands of cisco gurus in the supportforums.

guess i was wrong..

gamalielcruz
Level 1
Level 1

Try to add this to access list 2

deny ip ip 192.168.1.86

This should be on top of the permit statement.

Thanks.

Sent from Cisco Technical Support iPhone App

As previously mentioned, if you deny traffic on a statement it get's dropped, longest match wins, it matches, it's denied, it's dropped.

The router doesn't say Oh, we got dropped here, lt me see where else i can possibly push these packets now..

routes them to null0 and that's the end of them.

I appreciate trying to help, i really do. I'm just wondering where are the thousands of forum users with more than single digit post count like us two.

Hello nn cox,

>> As previously mentioned, if you deny traffic on a statement it get's dropped, longest match wins, it matches, it's denied, it's dropped.

This is not true, the real behaviour depends on application: for PBR a deny statement means that traffic matching the deny statement will be normally routed by destination, for NAT means the traffic matching the deny statement will be not translated.

About your issue, a possible approach could be is that of using PBR on internal interface + NAT with route-maps statements as suggested by Gamiel.

But to do a clean configuration we use different route-maps for PBR and for NAT

PBR route-map

access-list 101 permit host 192.168.1.86 any

access-list 102 deny host 192.168.1.86 any

access-list 102 permit ip 192.168.1.0 0.0.0.255 any

route-map PBR permit 10

match ip address 101

set interface Dialer0

route-map PBR permit 20

match ip address 102

set interface ATM0.1

interface Vlan1

ip policy route-map PBR

ip nat inside

this works on the internal interface on inbound traffic

NAT route-maps

route-map NAT1 permit 10

match ip address 101

match interface dialer0

route-map NAT2 permit 20

match ip address 102

match interface ATM0.1

ip nat inside source route-map NAT1 interface dialer0 overload

ip nat inside source route-map NAT2 interface ATM0.1 overload

Hope to help

Giuseppe

Hi Giuseppe,

Judging by your ranking status and your more than 12K posts i guess that's not the first time you gonna hear that.. but here it goes anyway..

YOU ROCK!

Thanks so much, managed to get it working as it should, appreciated.

gamalielcruz
Level 1
Level 1

Or try using the route map as source of your NAT instead of the access list.

ip nat inside source route-map MAP

Thanks!

That needs an exit interface, what would that be?

Exit interface is already declared in the route-map.

Review Cisco Networking products for a $25 gift card