cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
819
Views
0
Helpful
5
Replies

PBR on 1811 with dialer interfaces

jason00040
Level 1
Level 1

I have two dialers.  The ISP is on dialer3.  I have a work VPN on dialer0.  When the routing table is used I can control routes (dialers) taken by destination route statements with no issues.

unknown route is to dialer3

I have two hosts in the 192.168.1.0/24 subnet which unconditionally must use dialer0 to exit the router.  These are 192.168.1.245-246.  All other hosts are in same subnet.  So I set up PBR such that 192.168.1.240/8 would be set to use dialer0.  The ACL shows matches.  Term mon shows traffic allowed matching routedVPN ACL is allowed, but nothing is working.  Sometimes it doesn't even increment the route-map, sometimes it does.  Traceroute hits gateway, all subsequent hops fail.  Both dialers have ip nat outside.  BVI1 is the gateway at 192.168.1.254 with ip nat inside.

My intent is to key on the 241-246 IP's and send them out dialer0 with all other traffic to just use the routing table based on no PBR match.

ip access-list extended routedVPN
permit ip 192.168.1.240 0.0.0.7 any log-input

route-map WorkVPN permit 10
match ip address routedVPN
set interface Dialer0

interface BVI1
ip address 192.168.1.254 255.255.255.0
ip nat inside
ip policy route-map WorkVPN

ip nat inside source route-map WorkVPN interface Dialer0 overload

Any help is appreciated.

1 Accepted Solution

Accepted Solutions

Hello,

have you removed the 'log' keyword from the access lists ?

Q. Does Cisco IOS NAT support ACLs with a "log" keyword?

A. When you configure Cisco IOS NAT for dynamic NAT translation, an ACL is used to identify packets that can be translated. The current NAT architecture does not support ACLs with a "log" keyword.

View solution in original post

5 Replies 5

Hello,

first of all, remove the 'log-input' from your access list, as NAT doesn't  work well with ACL logging.

To log NAT activity, you can configure:

Router(config)#ip nat log translations syslog

a.alekseev
Level 7
Level 7

Should be...

ip access-list extended routedVPN
permit ip 192.168.1.240 0.0.0.7 any log-input

route-map WorkVPN permit 10
match ip address routedVPN
set interface Dialer0

route-map NAT_WorkVPN permit 10
match ip address routedVPN
match interface Dialer0

interface BVI1
ip address 192.168.1.254 255.255.255.0
ip nat inside
ip policy route-map WorkVPN

ip nat inside source route-map NAT_WorkVPN interface Dialer0 overload

after that show your dialer config and "debug dialer" with interesting traffic in the wire...

sho ip nat tran is showing the dialer0 IP for Inside Global, so the traffic is matching from the proper hosts, but it's acting like the hosts have no access.  I know it's because I had to deny them on the normal Internet ACL.

Stepping back a bit...

I now have two nat rules:
ip nat inside source route-map CenturyLink interface Dialer3 overload
ip nat inside source route-map NAT_WorkVPN interface Dialer0 overload

The CenturyLink rule uses this route-map
route-map CenturyLink permit 10
match ip address Internet_CenturyLink
match interface Dialer3

Which uses ACL:
ip access-list extended Internet_CenturyLink
permit ip 192.168.1.0 0.0.0.255 any

^^^ This works properly for the 192.168.1.0 subnet.

When I added in the ACL:
ip access-list extended routedVPN
permit ip 192.168.1.240 0.0.0.7 any log-input

For route-maps:
route-map WorkVPN permit 10
match ip address routedVPN
set interface Dialer0
!
route-map NAT_WorkVPN permit 10
match ip address routedVPN
match interface Dialer0

The traffic continued to use the CenturyLink nat rule.  So cleared ip route * and nat trans * but still had to deny the two hosts from the CenturyLink ACL ahead of the 192.168.1.0 entry like this:
ip access-list extended Internet_CenturyLink
deny ip host 192.168.1.241 any log-input
deny ip host 192.168.1.242 any log-input
permit ip 192.168.1.0 0.0.0.255 any

The the nat translations look right, but the hosts have no connection outside.
The Inside Global IP is the dialer IP so the matching is correct.
tcp 192.2X0.XX.19:58754 192.168.1.242:58754 176.32.XX.203:80 176.32.XX.203:80

Hello,

have you removed the 'log' keyword from the access lists ?

Q. Does Cisco IOS NAT support ACLs with a "log" keyword?

A. When you configure Cisco IOS NAT for dynamic NAT translation, an ACL is used to identify packets that can be translated. The current NAT architecture does not support ACLs with a "log" keyword.

jason00040
Level 1
Level 1

Thank you, Georg.  This seemed to fix it.

Review Cisco Networking for a $25 gift card